Podcasts about timescale

In this episode of ACM ByteCast, Rashmi Mohan hosts ACM Fellow Michael J. Freedman, Robert E. Kahn Professor of Computer Science at Princeton University and co-Founder and CTO of Timescale. Michael's research interests are in distributed systems, networking, and security. Over the course of his student and professional career, he designed and operated the Coral Content Distribution Network, a peer-to-peer content distribution network; co-founded (with Martin Casado) Illuminics Systems, an IP analytics company; and designed TimescaleDB and JetStream. His many honors and recognitions include the 2018 ACM Grace Murray Hopper Award, Presidential Early Career Award for Scientists and Engineers, and SIGOPS Mark Weiser Award. Michael shares what drew him to computer science, highlighting the value of initiative and gumption as an undergraduate student, and how he became interested in security and privacy, working on peer-to-peer systems before cloud computing became ubiquitous. He discusses his work on Coral CDN during his PhD research, applying research outcomes to build scalable systems and learning to harness customer feedback good user experience. Michael also talks extensively about Timescale, one of the fastest databases for real-time analytics, or time series data, and explains the roles of CTO and head engineer at a technology company.

Foundations of Amateur Radio Recently Glynn VK6PAW and I had the opportunity to play radio. This isn't something that happens often so we try to make the most of it. For our efforts we had plenty of frustrations, to the point where we were joking that I should rename this to "Frustrations of Amateur Radio". That was until we heard something weird on-air. All setup shenanigans forgotten, we marvelled at the experience. I was playing around on the 10m band, trying to hear people making noise and potentially our first contact for the field day we were participating in, when I heard something odd. Two stations talking to each other, but the audio was strange. It was like they were doubling up, the same audio played a fraction of a second later, until that moment, something I've only ever heard in a radio studio whilst editing using a reel-to-reel tape machine with separate recording and playback heads. Having just started using a digital only radio, at first I thought this was an artefact of the radio. I took note of the frequency, 28.460 MHz and told Glynn about it. After we moved the telescopic vertical antenna to the analogue radio, we discovered that this was in fact real, not caused by the radios, no doubt a relief to the proud owner of both radios, Glynn, who was thinking more clearly than I. He took note of the callsigns, Dom VK2HJ and Yukiharu JE1CSW. Looking back now, an audio recording would have been helpful. At the time I suggested that this might be a case of long path and short path signals arriving at our station and being able to hear both. If you're not sure what that means, when you transmit, an antenna essentially radiates in all directions and signals travel all over the globe. Some head directly towards your destination, the short path, others head in exactly the opposite direction, taking the long way around Earth, the long path. You might think that the majority of contacts are made using the short path, but it regularly happens the other way around, where the long path is heard and the short path is not. As you might know, radio waves essentially bounce up and down between the ionosphere and Earth and it might happen that the signal arrives at the destination antenna, or it might happen that it bounces right over the top, making either short path or long path heard, or not. In this case, both arrived clearly audible. It wasn't until I sat down on the couch afterwards with a calculator that I was able to at least prove to my own satisfaction that this is what we heard. So, what were those calculations and what was the delay? The circumference of Earth is roughly 40,000 km. RF propagation travels at the speed of light, or about 300,000 km/s. It takes about 0.13 seconds or 130 milliseconds for a radio signal to travel around Earth. At this point you might realise that 40,000 km is measured at the surface, but ionospheric propagation happens in the ionosphere, making the circumference at the very top of the ionosphere about 45,000 km, which would take 150 ms. There are several things that need to line up for this all to work. Propagation aside, the distance between all three stations needs to be such that the number of hops between each combination is a whole number so we can all hear each other. As it happens, the distance between Perth in Western Australia and Maebashi City in Japan is pretty close to the distance between Goulburn in New South Wales and Japan, and the distance between Goulburn and Perth is roughly half that. Using back of napkin trigonometry, it appears that 27 hops around the planet are required to make this happen. That's five hops between Perth and Japan, and between Goulburn and Japan, and two hops between Goulburn and Perth, and 27 hops between Perth and Japan the long way around. Given that the F2 layer where the 10m signal is refracted exists between about 220 km and 800 km, we can estimate that the total delay for the long path is at least 144 ms. That doesn't really translate into anything you might relate to, but at 8 wpm a Morse code dit takes 150 milliseconds, which gives you a sense of how long the echo delay is. In other words, it's something that you can absolutely hear without needing to measure it. There are other implications. WSPR signals are used to test weak signal propagation. Stations around the globe report on what they can hear and when. For this to work, the signal need to be synchronised, something which is commonly implemented using something called NTP, or Network Time Protocol. It can achieve a time accuracy of 10 ms. GPS locked WSPR beacons can achieve an accuracy of 40 nanoseconds. In other words, if we know that the beacon and the receiver are time synchronised, we can probably detect if the signal arrived using a short path or a long path. The WSPR decoder tracks the time between when the signal arrived and 2 seconds past an even minute as perceived by the receiver. Gwyn G3ZIL wrote an interesting document called "Timescale wsprdaemon database queries V2" on the subject of the data format used by wsprdaemon, a tool used to analyse WSPR beacon transmissions. If this is something you want to play with, check out wsprdaemon.org From our adventures there was plenty to take away. Stay curious, go portable, take notes, practice putting up an antenna, keep a log, laugh and have fun, and last but not least, get on air and make noise. Before I forget, make sure your mate brings a pen for logging when your own trusty scribble stick suddenly gives up the ghost for no apparent reason. I knew there was a reason I prefer pencils. I'm Onno VK6FLAB

Did you know that adding a simple Code Interpreter took o3 from 9.2% to 32% on FrontierMath? The Latent Space crew is hosting a hack night Feb 11th in San Francisco focused on CodeGen use cases, co-hosted with E2B and Edge AGI; watch E2B's new workshop and RSVP here!We're happy to announce that today's guest Samuel Colvin will be teaching his very first Pydantic AI workshop at the newly announced AI Engineer NYC Workshops day on Feb 22! 25 tickets left.If you're a Python developer, it's very likely that you've heard of Pydantic. Every month, it's downloaded >300,000,000 times, making it one of the top 25 PyPi packages. OpenAI uses it in its SDK for structured outputs, it's at the core of FastAPI, and if you've followed our AI Engineer Summit conference, Jason Liu of Instructor has given two great talks about it: “Pydantic is all you need” and “Pydantic is STILL all you need”. Now, Samuel Colvin has raised $17M from Sequoia to turn Pydantic from an open source project to a full stack AI engineer platform with Logfire, their observability platform, and PydanticAI, their new agent framework.Logfire: bringing OTEL to AIOpenTelemetry recently merged Semantic Conventions for LLM workloads which provides standard definitions to track performance like gen_ai.server.time_per_output_token. In Sam's view at least 80% of new apps being built today have some sort of LLM usage in them, and just like web observability platform got replaced by cloud-first ones in the 2010s, Logfire wants to do the same for AI-first apps. If you're interested in the technical details, Logfire migrated away from Clickhouse to Datafusion for their backend. We spent some time on the importance of picking open source tools you understand and that you can actually contribute to upstream, rather than the more popular ones; listen in ~43:19 for that part.Agents are the killer app for graphsPydantic AI is their attempt at taking a lot of the learnings that LangChain and the other early LLM frameworks had, and putting Python best practices into it. At an API level, it's very similar to the other libraries: you can call LLMs, create agents, do function calling, do evals, etc.They define an “Agent” as a container with a system prompt, tools, structured result, and an LLM. Under the hood, each Agent is now a graph of function calls that can orchestrate multi-step LLM interactions. You can start simple, then move toward fully dynamic graph-based control flow if needed.“We were compelled enough by graphs once we got them right that our agent implementation [...] is now actually a graph under the hood.”Why Graphs?* More natural for complex or multi-step AI workflows.* Easy to visualize and debug with mermaid diagrams.* Potential for distributed runs, or “waiting days” between steps in certain flows.In parallel, you see folks like Emil Eifrem of Neo4j talk about GraphRAG as another place where graphs fit really well in the AI stack, so it might be time for more people to take them seriously.Full Video EpisodeLike and subscribe!Chapters* 00:00:00 Introductions* 00:00:24 Origins of Pydantic* 00:05:28 Pydantic's AI moment * 00:08:05 Why build a new agents framework?* 00:10:17 Overview of Pydantic AI* 00:12:33 Becoming a believer in graphs* 00:24:02 God Model vs Compound AI Systems* 00:28:13 Why not build an LLM gateway?* 00:31:39 Programmatic testing vs live evals* 00:35:51 Using OpenTelemetry for AI traces* 00:43:19 Why they don't use Clickhouse* 00:48:34 Competing in the observability space* 00:50:41 Licensing decisions for Pydantic and LogFire* 00:51:48 Building Pydantic.run* 00:55:24 Marimo and the future of Jupyter notebooks* 00:57:44 London's AI sceneShow Notes* Sam Colvin* Pydantic* Pydantic AI* Logfire* Pydantic.run* Zod* E2B* Arize* Langsmith* Marimo* Prefect* GLA (Google Generative Language API)* OpenTelemetry* Jason Liu* Sebastian Ramirez* Bogomil Balkansky* Hood Chatham* Jeremy Howard* Andrew LambTranscriptAlessio [00:00:03]: Hey, everyone. Welcome to the Latent Space podcast. This is Alessio, partner and CTO at Decibel Partners, and I'm joined by my co-host Swyx, founder of Smol AI.Swyx [00:00:12]: Good morning. And today we're very excited to have Sam Colvin join us from Pydantic AI. Welcome. Sam, I heard that Pydantic is all we need. Is that true?Samuel [00:00:24]: I would say you might need Pydantic AI and Logfire as well, but it gets you a long way, that's for sure.Swyx [00:00:29]: Pydantic almost basically needs no introduction. It's almost 300 million downloads in December. And obviously, in the previous podcasts and discussions we've had with Jason Liu, he's been a big fan and promoter of Pydantic and AI.Samuel [00:00:45]: Yeah, it's weird because obviously I didn't create Pydantic originally for uses in AI, it predates LLMs. But it's like we've been lucky that it's been picked up by that community and used so widely.Swyx [00:00:58]: Actually, maybe we'll hear it. Right from you, what is Pydantic and maybe a little bit of the origin story?Samuel [00:01:04]: The best name for it, which is not quite right, is a validation library. And we get some tension around that name because it doesn't just do validation, it will do coercion by default. We now have strict mode, so you can disable that coercion. But by default, if you say you want an integer field and you get in a string of 1, 2, 3, it will convert it to 123 and a bunch of other sensible conversions. And as you can imagine, the semantics around it. Exactly when you convert and when you don't, it's complicated, but because of that, it's more than just validation. Back in 2017, when I first started it, the different thing it was doing was using type hints to define your schema. That was controversial at the time. It was genuinely disapproved of by some people. I think the success of Pydantic and libraries like FastAPI that build on top of it means that today that's no longer controversial in Python. And indeed, lots of other people have copied that route, but yeah, it's a data validation library. It uses type hints for the for the most part and obviously does all the other stuff you want, like serialization on top of that. But yeah, that's the core.Alessio [00:02:06]: Do you have any fun stories on how JSON schemas ended up being kind of like the structure output standard for LLMs? And were you involved in any of these discussions? Because I know OpenAI was, you know, one of the early adopters. So did they reach out to you? Was there kind of like a structure output console in open source that people were talking about or was it just a random?Samuel [00:02:26]: No, very much not. So I originally. Didn't implement JSON schema inside Pydantic and then Sebastian, Sebastian Ramirez, FastAPI came along and like the first I ever heard of him was over a weekend. I got like 50 emails from him or 50 like emails as he was committing to Pydantic, adding JSON schema long pre version one. So the reason it was added was for OpenAPI, which is obviously closely akin to JSON schema. And then, yeah, I don't know why it was JSON that got picked up and used by OpenAI. It was obviously very convenient for us. That's because it meant that not only can you do the validation, but because Pydantic will generate you the JSON schema, it will it kind of can be one source of source of truth for structured outputs and tools.Swyx [00:03:09]: Before we dive in further on the on the AI side of things, something I'm mildly curious about, obviously, there's Zod in JavaScript land. Every now and then there is a new sort of in vogue validation library that that takes over for quite a few years and then maybe like some something else comes along. Is Pydantic? Is it done like the core Pydantic?Samuel [00:03:30]: I've just come off a call where we were redesigning some of the internal bits. There will be a v3 at some point, which will not break people's code half as much as v2 as in v2 was the was the massive rewrite into Rust, but also fixing all the stuff that was broken back from like version zero point something that we didn't fix in v1 because it was a side project. We have plans to move some of the basically store the data in Rust types after validation. Not completely. So we're still working to design the Pythonic version of it, in order for it to be able to convert into Python types. So then if you were doing like validation and then serialization, you would never have to go via a Python type we reckon that can give us somewhere between three and five times another three to five times speed up. That's probably the biggest thing. Also, like changing how easy it is to basically extend Pydantic and define how particular types, like for example, NumPy arrays are validated and serialized. But there's also stuff going on. And for example, Jitter, the JSON library in Rust that does the JSON parsing, has SIMD implementation at the moment only for AMD64. So we can add that. We need to go and add SIMD for other instruction sets. So there's a bunch more we can do on performance. I don't think we're going to go and revolutionize Pydantic, but it's going to continue to get faster, continue, hopefully, to allow people to do more advanced things. We might add a binary format like CBOR for serialization for when you'll just want to put the data into a database and probably load it again from Pydantic. So there are some things that will come along, but for the most part, it should just get faster and cleaner.Alessio [00:05:04]: From a focus perspective, I guess, as a founder too, how did you think about the AI interest rising? And then how do you kind of prioritize, okay, this is worth going into more, and we'll talk about Pydantic AI and all of that. What was maybe your early experience with LLAMP, and when did you figure out, okay, this is something we should take seriously and focus more resources on it?Samuel [00:05:28]: I'll answer that, but I'll answer what I think is a kind of parallel question, which is Pydantic's weird, because Pydantic existed, obviously, before I was starting a company. I was working on it in my spare time, and then beginning of 22, I started working on the rewrite in Rust. And I worked on it full-time for a year and a half, and then once we started the company, people came and joined. And it was a weird project, because that would never go away. You can't get signed off inside a startup. Like, we're going to go off and three engineers are going to work full-on for a year in Python and Rust, writing like 30,000 lines of Rust just to release open-source-free Python library. The result of that has been excellent for us as a company, right? As in, it's made us remain entirely relevant. And it's like, Pydantic is not just used in the SDKs of all of the AI libraries, but I can't say which one, but one of the big foundational model companies, when they upgraded from Pydantic v1 to v2, their number one internal model... The metric of performance is time to first token. That went down by 20%. So you think about all of the actual AI going on inside, and yet at least 20% of the CPU, or at least the latency inside requests was actually Pydantic, which shows like how widely it's used. So we've benefited from doing that work, although it didn't, it would have never have made financial sense in most companies. In answer to your question about like, how do we prioritize AI, I mean, the honest truth is we've spent a lot of the last year and a half building. Good general purpose observability inside LogFire and making Pydantic good for general purpose use cases. And the AI has kind of come to us. Like we just, not that we want to get away from it, but like the appetite, uh, both in Pydantic and in LogFire to go and build with AI is enormous because it kind of makes sense, right? Like if you're starting a new greenfield project in Python today, what's the chance that you're using GenAI 80%, let's say, globally, obviously it's like a hundred percent in California, but even worldwide, it's probably 80%. Yeah. And so everyone needs that stuff. And there's so much yet to be figured out so much like space to do things better in the ecosystem in a way that like to go and implement a database that's better than Postgres is a like Sisyphean task. Whereas building, uh, tools that are better for GenAI than some of the stuff that's about now is not very difficult. Putting the actual models themselves to one side.Alessio [00:07:40]: And then at the same time, then you released Pydantic AI recently, which is, uh, um, you know, agent framework and early on, I would say everybody like, you know, Langchain and like, uh, Pydantic kind of like a first class support, a lot of these frameworks, we're trying to use you to be better. What was the decision behind we should do our own framework? Were there any design decisions that you disagree with any workloads that you think people didn't support? Well,Samuel [00:08:05]: it wasn't so much like design and workflow, although I think there were some, some things we've done differently. Yeah. I think looking in general at the ecosystem of agent frameworks, the engineering quality is far below that of the rest of the Python ecosystem. There's a bunch of stuff that we have learned how to do over the last 20 years of building Python libraries and writing Python code that seems to be abandoned by people when they build agent frameworks. Now I can kind of respect that, particularly in the very first agent frameworks, like Langchain, where they were literally figuring out how to go and do this stuff. It's completely understandable that you would like basically skip some stuff.Samuel [00:08:42]: I'm shocked by the like quality of some of the agent frameworks that have come out recently from like well-respected names, which it just seems to be opportunism and I have little time for that, but like the early ones, like I think they were just figuring out how to do stuff and just as lots of people have learned from Pydantic, we were able to learn a bit from them. I think from like the gap we saw and the thing we were frustrated by was the production readiness. And that means things like type checking, even if type checking makes it hard. Like Pydantic AI, I will put my hand up now and say it has a lot of generics and you need to, it's probably easier to use it if you've written a bit of Rust and you really understand generics, but like, and that is, we're not claiming that that makes it the easiest thing to use in all cases, we think it makes it good for production applications in big systems where type checking is a no-brainer in Python. But there are also a bunch of stuff we've learned from maintaining Pydantic over the years that we've gone and done. So every single example in Pydantic AI's documentation is run on Python. As part of tests and every single print output within an example is checked during tests. So it will always be up to date. And then a bunch of things that, like I say, are standard best practice within the rest of the Python ecosystem, but I'm not followed surprisingly by some AI libraries like coverage, linting, type checking, et cetera, et cetera, where I think these are no-brainers, but like weirdly they're not followed by some of the other libraries.Alessio [00:10:04]: And can you just give an overview of the framework itself? I think there's kind of like the. LLM calling frameworks, there are the multi-agent frameworks, there's the workflow frameworks, like what does Pydantic AI do?Samuel [00:10:17]: I glaze over a bit when I hear all of the different sorts of frameworks, but I like, and I will tell you when I built Pydantic, when I built Logfire and when I built Pydantic AI, my methodology is not to go and like research and review all of the other things. I kind of work out what I want and I go and build it and then feedback comes and we adjust. So the fundamental building block of Pydantic AI is agents. The exact definition of agents and how you want to define them. is obviously ambiguous and our things are probably sort of agent-lit, not that we would want to go and rename them to agent-lit, but like the point is you probably build them together to build something and most people will call an agent. So an agent in our case has, you know, things like a prompt, like system prompt and some tools and a structured return type if you want it, that covers the vast majority of cases. There are situations where you want to go further and the most complex workflows where you want graphs and I resisted graphs for quite a while. I was sort of of the opinion you didn't need them and you could use standard like Python flow control to do all of that stuff. I had a few arguments with people, but I basically came around to, yeah, I can totally see why graphs are useful. But then we have the problem that by default, they're not type safe because if you have a like add edge method where you give the names of two different edges, there's no type checking, right? Even if you go and do some, I'm not, not all the graph libraries are AI specific. So there's a, there's a graph library called, but it allows, it does like a basic runtime type checking. Ironically using Pydantic to try and make up for the fact that like fundamentally that graphs are not typed type safe. Well, I like Pydantic, but it did, that's not a real solution to have to go and run the code to see if it's safe. There's a reason that starting type checking is so powerful. And so we kind of, from a lot of iteration eventually came up with a system of using normally data classes to define nodes where you return the next node you want to call and where we're able to go and introspect the return type of a node to basically build the graph. And so the graph is. Yeah. Inherently type safe. And once we got that right, I, I wasn't, I'm incredibly excited about graphs. I think there's like masses of use cases for them, both in gen AI and other development, but also software's all going to have interact with gen AI, right? It's going to be like web. There's no longer be like a web department in a company is that there's just like all the developers are building for web building with databases. The same is going to be true for gen AI.Alessio [00:12:33]: Yeah. I see on your docs, you call an agent, a container that contains a system prompt function. Tools, structure, result, dependency type model, and then model settings. Are the graphs in your mind, different agents? Are they different prompts for the same agent? What are like the structures in your mind?Samuel [00:12:52]: So we were compelled enough by graphs once we got them right, that we actually merged the PR this morning. That means our agent implementation without changing its API at all is now actually a graph under the hood as it is built using our graph library. So graphs are basically a lower level tool that allow you to build these complex workflows. Our agents are technically one of the many graphs you could go and build. And we just happened to build that one for you because it's a very common, commonplace one. But obviously there are cases where you need more complex workflows where the current agent assumptions don't work. And that's where you can then go and use graphs to build more complex things.Swyx [00:13:29]: You said you were cynical about graphs. What changed your mind specifically?Samuel [00:13:33]: I guess people kept giving me examples of things that they wanted to use graphs for. And my like, yeah, but you could do that in standard flow control in Python became a like less and less compelling argument to me because I've maintained those systems that end up with like spaghetti code. And I could see the appeal of this like structured way of defining the workflow of my code. And it's really neat that like just from your code, just from your type hints, you can get out a mermaid diagram that defines exactly what can go and happen.Swyx [00:14:00]: Right. Yeah. You do have very neat implementation of sort of inferring the graph from type hints, I guess. Yeah. Is what I would call it. Yeah. I think the question always is I have gone back and forth. I used to work at Temporal where we would actually spend a lot of time complaining about graph based workflow solutions like AWS step functions. And we would actually say that we were better because you could use normal control flow that you already knew and worked with. Yours, I guess, is like a little bit of a nice compromise. Like it looks like normal Pythonic code. But you just have to keep in mind what the type hints actually mean. And that's what we do with the quote unquote magic that the graph construction does.Samuel [00:14:42]: Yeah, exactly. And if you look at the internal logic of actually running a graph, it's incredibly simple. It's basically call a node, get a node back, call that node, get a node back, call that node. If you get an end, you're done. We will add in soon support for, well, basically storage so that you can store the state between each node that's run. And then the idea is you can then distribute the graph and run it across computers. And also, I mean, the other weird, the other bit that's really valuable is across time. Because it's all very well if you look at like lots of the graph examples that like Claude will give you. If it gives you an example, it gives you this lovely enormous mermaid chart of like the workflow, for example, managing returns if you're an e-commerce company. But what you realize is some of those lines are literally one function calls another function. And some of those lines are wait six days for the customer to print their like piece of paper and put it in the post. And if you're writing like your demo. Project or your like proof of concept, that's fine because you can just say, and now we call this function. But when you're building when you're in real in real life, that doesn't work. And now how do we manage that concept to basically be able to start somewhere else in the in our code? Well, this graph implementation makes it incredibly easy because you just pass the node that is the start point for carrying on the graph and it continues to run. So it's things like that where I was like, yeah, I can just imagine how things I've done in the past would be fundamentally easier to understand if we had done them with graphs.Swyx [00:16:07]: You say imagine, but like right now, this pedantic AI actually resume, you know, six days later, like you said, or is this just like a theoretical thing we can go someday?Samuel [00:16:16]: I think it's basically Q&A. So there's an AI that's asking the user a question and effectively you then call the CLI again to continue the conversation. And it basically instantiates the node and calls the graph with that node again. Now, we don't have the logic yet for effectively storing state in the database between individual nodes that we're going to add soon. But like the rest of it is basically there.Swyx [00:16:37]: It does make me think that not only are you competing with Langchain now and obviously Instructor, and now you're going into sort of the more like orchestrated things like Airflow, Prefect, Daxter, those guys.Samuel [00:16:52]: Yeah, I mean, we're good friends with the Prefect guys and Temporal have the same investors as us. And I'm sure that my investor Bogomol would not be too happy if I was like, oh, yeah, by the way, as well as trying to take on Datadog. We're also going off and trying to take on Temporal and everyone else doing that. Obviously, we're not doing all of the infrastructure of deploying that right yet, at least. We're, you know, we're just building a Python library. And like what's crazy about our graph implementation is, sure, there's a bit of magic in like introspecting the return type, you know, extracting things from unions, stuff like that. But like the actual calls, as I say, is literally call a function and get back a thing and call that. It's like incredibly simple and therefore easy to maintain. The question is, how useful is it? Well, I don't know yet. I think we have to go and find out. We have a whole. We've had a slew of people joining our Slack over the last few days and saying, tell me how good Pydantic AI is. How good is Pydantic AI versus Langchain? And I refuse to answer. That's your job to go and find that out. Not mine. We built a thing. I'm compelled by it, but I'm obviously biased. The ecosystem will work out what the useful tools are.Swyx [00:17:52]: Bogomol was my board member when I was at Temporal. And I think I think just generally also having been a workflow engine investor and participant in this space, it's a big space. Like everyone needs different functions. I think the one thing that I would say like yours, you know, as a library, you don't have that much control of it over the infrastructure. I do like the idea that each new agents or whatever or unit of work, whatever you call that should spin up in this sort of isolated boundaries. Whereas yours, I think around everything runs in the same process. But you ideally want to sort of spin out its own little container of things.Samuel [00:18:30]: I agree with you a hundred percent. And we will. It would work now. Right. As in theory, you're just like as long as you can serialize the calls to the next node, you just have to all of the different containers basically have to have the same the same code. I mean, I'm super excited about Cloudflare workers running Python and being able to install dependencies. And if Cloudflare could only give me my invitation to the private beta of that, we would be exploring that right now because I'm super excited about that as a like compute level for some of this stuff where exactly what you're saying, basically. You can run everything as an individual. Like worker function and distribute it. And it's resilient to failure, et cetera, et cetera.Swyx [00:19:08]: And it spins up like a thousand instances simultaneously. You know, you want it to be sort of truly serverless at once. Actually, I know we have some Cloudflare friends who are listening, so hopefully they'll get in front of the line. Especially.Samuel [00:19:19]: I was in Cloudflare's office last week shouting at them about other things that frustrate me. I have a love-hate relationship with Cloudflare. Their tech is awesome. But because I use it the whole time, I then get frustrated. So, yeah, I'm sure I will. I will. I will get there soon.Swyx [00:19:32]: There's a side tangent on Cloudflare. Is Python supported at full? I actually wasn't fully aware of what the status of that thing is.Samuel [00:19:39]: Yeah. So Pyodide, which is Python running inside the browser in scripting, is supported now by Cloudflare. They basically, they're having some struggles working out how to manage, ironically, dependencies that have binaries, in particular, Pydantic. Because these workers where you can have thousands of them on a given metal machine, you don't want to have a difference. You basically want to be able to have a share. Shared memory for all the different Pydantic installations, effectively. That's the thing they work out. They're working out. But Hood, who's my friend, who is the primary maintainer of Pyodide, works for Cloudflare. And that's basically what he's doing, is working out how to get Python running on Cloudflare's network.Swyx [00:20:19]: I mean, the nice thing is that your binary is really written in Rust, right? Yeah. Which also compiles the WebAssembly. Yeah. So maybe there's a way that you'd build... You have just a different build of Pydantic and that ships with whatever your distro for Cloudflare workers is.Samuel [00:20:36]: Yes, that's exactly what... So Pyodide has builds for Pydantic Core and for things like NumPy and basically all of the popular binary libraries. Yeah. It's just basic. And you're doing exactly that, right? You're using Rust to compile the WebAssembly and then you're calling that shared library from Python. And it's unbelievably complicated, but it works. Okay.Swyx [00:20:57]: Staying on graphs a little bit more, and then I wanted to go to some of the other features that you have in Pydantic AI. I see in your docs, there are sort of four levels of agents. There's single agents, there's agent delegation, programmatic agent handoff. That seems to be what OpenAI swarms would be like. And then the last one, graph-based control flow. Would you say that those are sort of the mental hierarchy of how these things go?Samuel [00:21:21]: Yeah, roughly. Okay.Swyx [00:21:22]: You had some expression around OpenAI swarms. Well.Samuel [00:21:25]: And indeed, OpenAI have got in touch with me and basically, maybe I'm not supposed to say this, but basically said that Pydantic AI looks like what swarms would become if it was production ready. So, yeah. I mean, like, yeah, which makes sense. Awesome. Yeah. I mean, in fact, it was specifically saying, how can we give people the same feeling that they were getting from swarms that led us to go and implement graphs? Because my, like, just call the next agent with Python code was not a satisfactory answer to people. So it was like, okay, we've got to go and have a better answer for that. It's not like, let us to get to graphs. Yeah.Swyx [00:21:56]: I mean, it's a minimal viable graph in some sense. What are the shapes of graphs that people should know? So the way that I would phrase this is I think Anthropic did a very good public service and also kind of surprisingly influential blog post, I would say, when they wrote Building Effective Agents. We actually have the authors coming to speak at my conference in New York, which I think you're giving a workshop at. Yeah.Samuel [00:22:24]: I'm trying to work it out. But yes, I think so.Swyx [00:22:26]: Tell me if you're not. yeah, I mean, like, that was the first, I think, authoritative view of, like, what kinds of graphs exist in agents and let's give each of them a name so that everyone is on the same page. So I'm just kind of curious if you have community names or top five patterns of graphs.Samuel [00:22:44]: I don't have top five patterns of graphs. I would love to see what people are building with them. But like, it's been it's only been a couple of weeks. And of course, there's a point is that. Because they're relatively unopinionated about what you can go and do with them. They don't suit them. Like, you can go and do lots of lots of things with them, but they don't have the structure to go and have like specific names as much as perhaps like some other systems do. I think what our agents are, which have a name and I can't remember what it is, but this basically system of like, decide what tool to call, go back to the center, decide what tool to call, go back to the center and then exit. One form of graph, which, as I say, like our agents are effectively one implementation of a graph, which is why under the hood they are now using graphs. And it'll be interesting to see over the next few years whether we end up with these like predefined graph names or graph structures or whether it's just like, yep, I built a graph or whether graphs just turn out not to match people's mental image of what they want and die away. We'll see.Swyx [00:23:38]: I think there is always appeal. Every developer eventually gets graph religion and goes, oh, yeah, everything's a graph. And then they probably over rotate and go go too far into graphs. And then they have to learn a whole bunch of DSLs. And then they're like, actually, I didn't need that. I need this. And they scale back a little bit.Samuel [00:23:55]: I'm at the beginning of that process. I'm currently a graph maximalist, although I haven't actually put any into production yet. But yeah.Swyx [00:24:02]: This has a lot of philosophical connections with other work coming out of UC Berkeley on compounding AI systems. I don't know if you know of or care. This is the Gartner world of things where they need some kind of industry terminology to sell it to enterprises. I don't know if you know about any of that.Samuel [00:24:24]: I haven't. I probably should. I should probably do it because I should probably get better at selling to enterprises. But no, no, I don't. Not right now.Swyx [00:24:29]: This is really the argument is that instead of putting everything in one model, you have more control and more maybe observability to if you break everything out into composing little models and changing them together. And obviously, then you need an orchestration framework to do that. Yeah.Samuel [00:24:47]: And it makes complete sense. And one of the things we've seen with agents is they work well when they work well. But when they. Even if you have the observability through log five that you can see what was going on, if you don't have a nice hook point to say, hang on, this is all gone wrong. You have a relatively blunt instrument of basically erroring when you exceed some kind of limit. But like what you need to be able to do is effectively iterate through these runs so that you can have your own control flow where you're like, OK, we've gone too far. And that's where one of the neat things about our graph implementation is you can basically call next in a loop rather than just running the full graph. And therefore, you have this opportunity to to break out of it. But yeah, basically, it's the same point, which is like if you have two bigger unit of work to some extent, whether or not it involves gen AI. But obviously, it's particularly problematic in gen AI. You only find out afterwards when you've spent quite a lot of time and or money when it's gone off and done done the wrong thing.Swyx [00:25:39]: Oh, drop on this. We're not going to resolve this here, but I'll drop this and then we can move on to the next thing. This is the common way that we we developers talk about this. And then the machine learning researchers look at us. And laugh and say, that's cute. And then they just train a bigger model and they wipe us out in the next training run. So I think there's a certain amount of we are fighting the bitter lesson here. We're fighting AGI. And, you know, when AGI arrives, this will all go away. Obviously, on Latent Space, we don't really discuss that because I think AGI is kind of this hand wavy concept that isn't super relevant. But I think we have to respect that. For example, you could do a chain of thoughts with graphs and you could manually orchestrate a nice little graph that does like. Reflect, think about if you need more, more inference time, compute, you know, that's the hot term now. And then think again and, you know, scale that up. Or you could train Strawberry and DeepSeq R1. Right.Samuel [00:26:32]: I saw someone saying recently, oh, they were really optimistic about agents because models are getting faster exponentially. And I like took a certain amount of self-control not to describe that it wasn't exponential. But my main point was. If models are getting faster as quickly as you say they are, then we don't need agents and we don't really need any of these abstraction layers. We can just give our model and, you know, access to the Internet, cross our fingers and hope for the best. Agents, agent frameworks, graphs, all of this stuff is basically making up for the fact that right now the models are not that clever. In the same way that if you're running a customer service business and you have loads of people sitting answering telephones, the less well trained they are, the less that you trust them, the more that you need to give them a script to go through. Whereas, you know, so if you're running a bank and you have lots of customer service people who you don't trust that much, then you tell them exactly what to say. If you're doing high net worth banking, you just employ people who you think are going to be charming to other rich people and set them off to go and have coffee with people. Right. And the same is true of models. The more intelligent they are, the less we need to tell them, like structure what they go and do and constrain the routes in which they take.Swyx [00:27:42]: Yeah. Yeah. Agree with that. So I'm happy to move on. So the other parts of Pydantic AI that are worth commenting on, and this is like my last rant, I promise. So obviously, every framework needs to do its sort of model adapter layer, which is, oh, you can easily swap from OpenAI to Cloud to Grok. You also have, which I didn't know about, Google GLA, which I didn't really know about until I saw this in your docs, which is generative language API. I assume that's AI Studio? Yes.Samuel [00:28:13]: Google don't have good names for it. So Vertex is very clear. That seems to be the API that like some of the things use, although it returns 503 about 20% of the time. So... Vertex? No. Vertex, fine. But the... Oh, oh. GLA. Yeah. Yeah.Swyx [00:28:28]: I agree with that.Samuel [00:28:29]: So we have, again, another example of like, well, I think we go the extra mile in terms of engineering is we run on every commit, at least commit to main, we run tests against the live models. Not lots of tests, but like a handful of them. Oh, okay. And we had a point last week where, yeah, GLA is a little bit better. GLA1 was failing every single run. One of their tests would fail. And we, I think we might even have commented out that one at the moment. So like all of the models fail more often than you might expect, but like that one seems to be particularly likely to fail. But Vertex is the same API, but much more reliable.Swyx [00:29:01]: My rant here is that, you know, versions of this appear in Langchain and every single framework has to have its own little thing, a version of that. I would put to you, and then, you know, this is, this can be agree to disagree. This is not needed in Pydantic AI. I would much rather you adopt a layer like Lite LLM or what's the other one in JavaScript port key. And that's their job. They focus on that one thing and they, they normalize APIs for you. All new models are automatically added and you don't have to duplicate this inside of your framework. So for example, if I wanted to use deep seek, I'm out of luck because Pydantic AI doesn't have deep seek yet.Samuel [00:29:38]: Yeah, it does.Swyx [00:29:39]: Oh, it does. Okay. I'm sorry. But you know what I mean? Should this live in your code or should it live in a layer that's kind of your API gateway that's a defined piece of infrastructure that people have?Samuel [00:29:49]: And I think if a company who are well known, who are respected by everyone had come along and done this at the right time, maybe we should have done it a year and a half ago and said, we're going to be the universal AI layer. That would have been a credible thing to do. I've heard varying reports of Lite LLM is the truth. And it didn't seem to have exactly the type safety that we needed. Also, as I understand it, and again, I haven't looked into it in great detail. Part of their business model is proxying the request through their, through their own system to do the generalization. That would be an enormous put off to an awful lot of people. Honestly, the truth is I don't think it is that much work unifying the model. I get where you're coming from. I kind of see your point. I think the truth is that everyone is centralizing around open AIs. Open AI's API is the one to do. So DeepSeq support that. Grok with OK support that. Ollama also does it. I mean, if there is that library right now, it's more or less the open AI SDK. And it's very high quality. It's well type checked. It uses Pydantic. So I'm biased. But I mean, I think it's pretty well respected anyway.Swyx [00:30:57]: There's different ways to do this. Because also, it's not just about normalizing the APIs. You have to do secret management and all that stuff.Samuel [00:31:05]: Yeah. And there's also. There's Vertex and Bedrock, which to one extent or another, effectively, they host multiple models, but they don't unify the API. But they do unify the auth, as I understand it. Although we're halfway through doing Bedrock. So I don't know about it that well. But they're kind of weird hybrids because they support multiple models. But like I say, the auth is centralized.Swyx [00:31:28]: Yeah, I'm surprised they don't unify the API. That seems like something that I would do. You know, we can discuss all this all day. There's a lot of APIs. I agree.Samuel [00:31:36]: It would be nice if there was a universal one that we didn't have to go and build.Alessio [00:31:39]: And I guess the other side of, you know, routing model and picking models like evals. How do you actually figure out which one you should be using? I know you have one. First of all, you have very good support for mocking in unit tests, which is something that a lot of other frameworks don't do. So, you know, my favorite Ruby library is VCR because it just, you know, it just lets me store the HTTP requests and replay them. That part I'll kind of skip. I think you are busy like this test model. We're like just through Python. You try and figure out what the model might respond without actually calling the model. And then you have the function model where people can kind of customize outputs. Any other fun stories maybe from there? Or is it just what you see is what you get, so to speak?Samuel [00:32:18]: On those two, I think what you see is what you get. On the evals, I think watch this space. I think it's something that like, again, I was somewhat cynical about for some time. Still have my cynicism about some of the well, it's unfortunate that so many different things are called evals. It would be nice if we could agree. What they are and what they're not. But look, I think it's a really important space. I think it's something that we're going to be working on soon, both in Pydantic AI and in LogFire to try and support better because it's like it's an unsolved problem.Alessio [00:32:45]: Yeah, you do say in your doc that anyone who claims to know for sure exactly how your eval should be defined can safely be ignored.Samuel [00:32:52]: We'll delete that sentence when we tell people how to do their evals.Alessio [00:32:56]: Exactly. I was like, we need we need a snapshot of this today. And so let's talk about eval. So there's kind of like the vibe. Yeah. So you have evals, which is what you do when you're building. Right. Because you cannot really like test it that many times to get statistical significance. And then there's the production eval. So you also have LogFire, which is kind of like your observability product, which I tried before. It's very nice. What are some of the learnings you've had from building an observability tool for LEMPs? And yeah, as people think about evals, even like what are the right things to measure? What are like the right number of samples that you need to actually start making decisions?Samuel [00:33:33]: I'm not the best person to answer that is the truth. So I'm not going to come in here and tell you that I think I know the answer on the exact number. I mean, we can do some back of the envelope statistics calculations to work out that like having 30 probably gets you most of the statistical value of having 200 for, you know, by definition, 15% of the work. But the exact like how many examples do you need? For example, that's a much harder question to answer because it's, you know, it's deep within the how models operate in terms of LogFire. One of the reasons we built LogFire the way we have and we allow you to write SQL directly against your data and we're trying to build the like powerful fundamentals of observability is precisely because we know we don't know the answers. And so allowing people to go and innovate on how they're going to consume that stuff and how they're going to process it is we think that's valuable. Because even if we come along and offer you an evals framework on top of LogFire, it won't be right in all regards. And we want people to be able to go and innovate and being able to write their own SQL connected to the API. And effectively query the data like it's a database with SQL allows people to innovate on that stuff. And that's what allows us to do it as well. I mean, we do a bunch of like testing what's possible by basically writing SQL directly against LogFire as any user could. I think the other the other really interesting bit that's going on in observability is OpenTelemetry is centralizing around semantic attributes for GenAI. So it's a relatively new project. A lot of it's still being added at the moment. But basically the idea that like. They unify how both SDKs and or agent frameworks send observability data to to any OpenTelemetry endpoint. And so, again, we can go and having that unification allows us to go and like basically compare different libraries, compare different models much better. That stuff's in a very like early stage of development. One of the things we're going to be working on pretty soon is basically, I suspect, GenAI will be the first agent framework that implements those semantic attributes properly. Because, again, we control and we can say this is important for observability, whereas most of the other agent frameworks are not maintained by people who are trying to do observability. With the exception of Langchain, where they have the observability platform, but they chose not to go down the OpenTelemetry route. So they're like plowing their own furrow. And, you know, they're a lot they're even further away from standardization.Alessio [00:35:51]: Can you maybe just give a quick overview of how OTEL ties into the AI workflows? There's kind of like the question of is, you know, a trace. And a span like a LLM call. Is it the agent? It's kind of like the broader thing you're tracking. How should people think about it?Samuel [00:36:06]: Yeah, so they have a PR that I think may have now been merged from someone at IBM talking about remote agents and trying to support this concept of remote agents within GenAI. I'm not particularly compelled by that because I don't think that like that's actually by any means the common use case. But like, I suppose it's fine for it to be there. The majority of the stuff in OTEL is basically defining how you would instrument. A given call to an LLM. So basically the actual LLM call, what data you would send to your telemetry provider, how you would structure that. Apart from this slightly odd stuff on remote agents, most of the like agent level consideration is not yet implemented in is not yet decided effectively. And so there's a bit of ambiguity. Obviously, what's good about OTEL is you can in the end send whatever attributes you like. But yeah, there's quite a lot of churn in that space and exactly how we store the data. I think that one of the most interesting things, though, is that if you think about observability. Traditionally, it was sure everyone would say our observability data is very important. We must keep it safe. But actually, companies work very hard to basically not have anything that sensitive in their observability data. So if you're a doctor in a hospital and you search for a drug for an STI, the sequel might be sent to the observability provider. But none of the parameters would. It wouldn't have the patient number or their name or the drug. With GenAI, that distinction doesn't exist because it's all just messed up in the text. If you have that same patient asking an LLM how to. What drug they should take or how to stop smoking. You can't extract the PII and not send it to the observability platform. So the sensitivity of the data that's going to end up in observability platforms is going to be like basically different order of magnitude to what's in what you would normally send to Datadog. Of course, you can make a mistake and send someone's password or their card number to Datadog. But that would be seen as a as a like mistake. Whereas in GenAI, a lot of data is going to be sent. And I think that's why companies like Langsmith and are trying hard to offer observability. On prem, because there's a bunch of companies who are happy for Datadog to be cloud hosted, but want self-hosted self-hosting for this observability stuff with GenAI.Alessio [00:38:09]: And are you doing any of that today? Because I know in each of the spans you have like the number of tokens, you have the context, you're just storing everything. And then you're going to offer kind of like a self-hosting for the platform, basically. Yeah. Yeah.Samuel [00:38:23]: So we have scrubbing roughly equivalent to what the other observability platforms have. So if we, you know, if we see password as the key, we won't send the value. But like, like I said, that doesn't really work in GenAI. So we're accepting we're going to have to store a lot of data and then we'll offer self-hosting for those people who can afford it and who need it.Alessio [00:38:42]: And then this is, I think, the first time that most of the workloads performance is depending on a third party. You know, like if you're looking at Datadog data, usually it's your app that is driving the latency and like the memory usage and all of that. Here you're going to have spans that maybe take a long time to perform because the GLA API is not working or because OpenAI is kind of like overwhelmed. Do you do anything there since like the provider is almost like the same across customers? You know, like, are you trying to surface these things for people and say, hey, this was like a very slow span, but actually all customers using OpenAI right now are seeing the same thing. So maybe don't worry about it or.Samuel [00:39:20]: Not yet. We do a few things that people don't generally do in OTA. So we send. We send information at the beginning. At the beginning of a trace as well as sorry, at the beginning of a span, as well as when it finishes. By default, OTA only sends you data when the span finishes. So if you think about a request which might take like 20 seconds, even if some of the intermediate spans finished earlier, you can't basically place them on the page until you get the top level span. And so if you're using standard OTA, you can't show anything until those requests are finished. When those requests are taking a few hundred milliseconds, it doesn't really matter. But when you're doing Gen AI calls or when you're like running a batch job that might take 30 minutes. That like latency of not being able to see the span is like crippling to understanding your application. And so we've we do a bunch of slightly complex stuff to basically send data about a span as it starts, which is closely related. Yeah.Alessio [00:40:09]: Any thoughts on all the other people trying to build on top of OpenTelemetry in different languages, too? There's like the OpenLEmetry project, which doesn't really roll off the tongue. But how do you see the future of these kind of tools? Is everybody going to have to build? Why does everybody want to build? They want to build their own open source observability thing to then sell?Samuel [00:40:29]: I mean, we are not going off and trying to instrument the likes of the OpenAI SDK with the new semantic attributes, because at some point that's going to happen and it's going to live inside OTEL and we might help with it. But we're a tiny team. We don't have time to go and do all of that work. So OpenLEmetry, like interesting project. But I suspect eventually most of those semantic like that instrumentation of the big of the SDKs will live, like I say, inside the main OpenTelemetry report. I suppose. What happens to the agent frameworks? What data you basically need at the framework level to get the context is kind of unclear. I don't think we know the answer yet. But I mean, I was on the, I guess this is kind of semi-public, because I was on the call with the OpenTelemetry call last week talking about GenAI. And there was someone from Arize talking about the challenges they have trying to get OpenTelemetry data out of Langchain, where it's not like natively implemented. And obviously they're having quite a tough time. And I was realizing, hadn't really realized this before, but how lucky we are to primarily be talking about our own agent framework, where we have the control rather than trying to go and instrument other people's.Swyx [00:41:36]: Sorry, I actually didn't know about this semantic conventions thing. It looks like, yeah, it's merged into main OTel. What should people know about this? I had never heard of it before.Samuel [00:41:45]: Yeah, I think it looks like a great start. I think there's some unknowns around how you send the messages that go back and forth, which is kind of the most important part. It's the most important thing of all. And that is moved out of attributes and into OTel events. OTel events in turn are moving from being on a span to being their own top-level API where you send data. So there's a bunch of churn still going on. I'm impressed by how fast the OTel community is moving on this project. I guess they, like everyone else, get that this is important, and it's something that people are crying out to get instrumentation off. So I'm kind of pleasantly surprised at how fast they're moving, but it makes sense.Swyx [00:42:25]: I'm just kind of browsing through the specification. I can already see that this basically bakes in whatever the previous paradigm was. So now they have genai.usage.prompt tokens and genai.usage.completion tokens. And obviously now we have reasoning tokens as well. And then only one form of sampling, which is top-p. You're basically baking in or sort of reifying things that you think are important today, but it's not a super foolproof way of doing this for the future. Yeah.Samuel [00:42:54]: I mean, that's what's neat about OTel is you can always go and send another attribute and that's fine. It's just there are a bunch that are agreed on. But I would say, you know, to come back to your previous point about whether or not we should be relying on one centralized abstraction layer, this stuff is moving so fast that if you start relying on someone else's standard, you risk basically falling behind because you're relying on someone else to keep things up to date.Swyx [00:43:14]: Or you fall behind because you've got other things going on.Samuel [00:43:17]: Yeah, yeah. That's fair. That's fair.Swyx [00:43:19]: Any other observations just about building LogFire, actually? Let's just talk about this. So you announced LogFire. I was kind of only familiar with LogFire because of your Series A announcement. I actually thought you were making a separate company. I remember some amount of confusion with you when that came out. So to be clear, it's Pydantic LogFire and the company is one company that has kind of two products, an open source thing and an observability thing, correct? Yeah. I was just kind of curious, like any learnings building LogFire? So classic question is, do you use ClickHouse? Is this like the standard persistence layer? Any learnings doing that?Samuel [00:43:54]: We don't use ClickHouse. We started building our database with ClickHouse, moved off ClickHouse onto Timescale, which is a Postgres extension to do analytical databases. Wow. And then moved off Timescale onto DataFusion. And we're basically now building, it's DataFusion, but it's kind of our own database. Bogomil is not entirely happy that we went through three databases before we chose one. I'll say that. But like, we've got to the right one in the end. I think we could have realized that Timescale wasn't right. I think ClickHouse. They both taught us a lot and we're in a great place now. But like, yeah, it's been a real journey on the database in particular.Swyx [00:44:28]: Okay. So, you know, as a database nerd, I have to like double click on this, right? So ClickHouse is supposed to be the ideal backend for anything like this. And then moving from ClickHouse to Timescale is another counterintuitive move that I didn't expect because, you know, Timescale is like an extension on top of Postgres. Not super meant for like high volume logging. But like, yeah, tell us those decisions.Samuel [00:44:50]: So at the time, ClickHouse did not have good support for JSON. I was speaking to someone yesterday and said ClickHouse doesn't have good support for JSON and got roundly stepped on because apparently it does now. So they've obviously gone and built their proper JSON support. But like back when we were trying to use it, I guess a year ago or a bit more than a year ago, everything happened to be a map and maps are a pain to try and do like looking up JSON type data. And obviously all these attributes, everything you're talking about there in terms of the GenAI stuff. You can choose to make them top level columns if you want. But the simplest thing is just to put them all into a big JSON pile. And that was a problem with ClickHouse. Also, ClickHouse had some really ugly edge cases like by default, or at least until I complained about it a lot, ClickHouse thought that two nanoseconds was longer than one second because they compared intervals just by the number, not the unit. And I complained about that a lot. And then they caused it to raise an error and just say you have to have the same unit. Then I complained a bit more. And I think as I understand it now, they have some. They convert between units. But like stuff like that, when all you're looking at is when a lot of what you're doing is comparing the duration of spans was really painful. Also things like you can't subtract two date times to get an interval. You have to use the date sub function. But like the fundamental thing is because we want our end users to write SQL, the like quality of the SQL, how easy it is to write, matters way more to us than if you're building like a platform on top where your developers are going to write the SQL. And once it's written and it's working, you don't mind too much. So I think that's like one of the fundamental differences. The other problem that I have with the ClickHouse and Impact Timescale is that like the ultimate architecture, the like snowflake architecture of binary data in object store queried with some kind of cache from nearby. They both have it, but it's closed sourced and you only get it if you go and use their hosted versions. And so even if we had got through all the problems with Timescale or ClickHouse, we would end up like, you know, they would want to be taking their 80% margin. And then we would be wanting to take that would basically leave us less space for margin. Whereas data fusion. Properly open source, all of that same tooling is open source. And for us as a team of people with a lot of Rust expertise, data fusion, which is implemented in Rust, we can literally dive into it and go and change it. So, for example, I found that there were some slowdowns in data fusion's string comparison kernel for doing like string contains. And it's just Rust code. And I could go and rewrite the string comparison kernel to be faster. Or, for example, data fusion, when we started using it, didn't have JSON support. Obviously, as I've said, it's something we can do. It's something we needed. I was able to go and implement that in a weekend using our JSON parser that we built for Pydantic Core. So it's the fact that like data fusion is like for us the perfect mixture of a toolbox to build a database with, not a database. And we can go and implement stuff on top of it in a way that like if you were trying to do that in Postgres or in ClickHouse. I mean, ClickHouse would be easier because it's C++, relatively modern C++. But like as a team of people who are not C++ experts, that's much scarier than data fusion for us.Swyx [00:47:47]: Yeah, that's a beautiful rant.Alessio [00:47:49]: That's funny. Most people don't think they have agency on these projects. They're kind of like, oh, I should use this or I should use that. They're not really like, what should I pick so that I contribute the most back to it? You know, so but I think you obviously have an open source first mindset. So that makes a lot of sense.Samuel [00:48:05]: I think if we were probably better as a startup, a better startup and faster moving and just like headlong determined to get in front of customers as fast as possible, we should have just started with ClickHouse. I hope that long term we're in a better place for having worked with data fusion. We like we're quite engaged now with the data fusion community. Andrew Lam, who maintains data fusion, is an advisor to us. We're in a really good place now. But yeah, it's definitely slowed us down relative to just like building on ClickHouse and moving as fast as we can.Swyx [00:48:34]: OK, we're about to zoom out and do Pydantic run and all the other stuff. But, you know, my last question on LogFire is really, you know, at some point you run out sort of community goodwill just because like, oh, I use Pydantic. I love Pydantic. I'm going to use LogFire. OK, then you start entering the territory of the Datadogs, the Sentrys and the honeycombs. Yeah. So where are you going to really spike here? What differentiator here?Samuel [00:48:59]: I wasn't writing code in 2001, but I'm assuming that there were people talking about like web observability and then web observability stopped being a thing, not because the web stopped being a thing, but because all observability had to do web. If you were talking to people in 2010 or 2012, they would have talked about cloud observability. Now that's not a term because all observability is cloud first. The same is going to happen to gen AI. And so whether or not you're trying to compete with Datadog or with Arise and Langsmith, you've got to do first class. You've got to do general purpose observability with first class support for AI. And as far as I know, we're the only people really trying to do that. I mean, I think Datadog is starting in that direction. And to be honest, I think Datadog is a much like scarier company to compete with than the AI specific observability platforms. Because in my opinion, and I've also heard this from lots of customers, AI specific observability where you don't see everything else going on in your app is not actually that useful. Our hope is that we can build the first general purpose observability platform with first class support for AI. And that we have this open source heritage of putting developer experience first that other companies haven't done. For all I'm a fan of Datadog and what they've done. If you search Datadog logging Python. And you just try as a like a non-observability expert to get something up and running with Datadog and Python. It's not trivial, right? That's something Sentry have done amazingly well. But like there's enormous space in most of observability to do DX better.Alessio [00:50:27]: Since you mentioned Sentry, I'm curious how you thought about licensing and all of that. Obviously, your MIT license, you don't have any rolling license like Sentry has where you can only use an open source, like the one year old version of it. Was that a hard decision?Samuel [00:50:41]: So to be clear, LogFire is co-sourced. So Pydantic and Pydantic AI are MIT licensed and like properly open source. And then LogFire for now is completely closed source. And in fact, the struggles that Sentry have had with licensing and the like weird pushback the community gives when they take something that's closed source and make it source available just meant that we just avoided that whole subject matter. I think the other way to look at it is like in terms of either headcount or revenue or dollars in the bank. The amount of open source we do as a company is we've got to be open source. We're up there with the most prolific open source companies, like I say, per head. And so we didn't feel like we were morally obligated to make LogFire open source. We have Pydantic. Pydantic is a foundational library in Python. That and now Pydantic AI are our contribution to open source. And then LogFire is like openly for profit, right? As in we're not claiming otherwise. We're not sort of trying to walk a line if it's open source. But really, we want to make it hard to deploy. So you probably want to pay us. We're trying to be straight. That it's to pay for. We could change that at some point in the future, but it's not an immediate plan.Alessio [00:51:48]: All right. So the first one I saw this new I don't know if it's like a product you're building the Pydantic that run, which is a Python browser sandbox. What was the inspiration behind that? We talk a lot about code interpreter for lamps. I'm an investor in a company called E2B, which is a code sandbox as a service for remote execution. Yeah. What's the Pydantic that run story?Samuel [00:52:09]: So Pydantic that run is again completely open source. I have no interest in making it into a product. We just needed a sandbox to be able to demo LogFire in particular, but also Pydantic AI. So it doesn't have it yet, but I'm going to add basically a proxy to OpenAI and the other models so that you can run Pydantic AI in the browser. See how it works. Tweak the prompt, et cetera, et cetera. And we'll have some kind of limit per day of what you can spend on it or like what the spend is. The other thing we wanted to b

This episode is sponsored by Netsuite by Oracle, the number one cloud financial system, streamlining accounting, financial management, inventory, HR, and more.   NetSuite is offering a one-of-a-kind flexible financing program. Head to  https://netsuite.com/EYEONAI to know more.     In this episode of the Eye on AI podcast, Avthar Sewrathan, Lead Technical Product Marketing Manager at Timescale joins Craig Smith to explore how Postgres is transforming AI development with cutting-edge tools and open-source innovation.   With its robust, extensible framework, Postgres has become the go-to database for AI applications, from semantic search to retrieval-augmented generation (RAG). Avthar takes us through Timescale's journey from its IoT origins to disrupting the way developers handle vector search, embedding management, and high-performance AI workloads—all within Postgres.   We dive into Timescale's tools like PGVector, PGVector Scale, and PGAI Vectorizer, uncovering how they aid developers to build AI-powered systems without the complexity of managing multiple databases. Avthar explains how Postgres seamlessly handles structured and unstructured data, making it the perfect foundation for next-gen AI applications.   Learn how Postgres supports AI-driven use cases across industries like IoT, finance, and crypto, and why its open-source ecosystem is key to fostering collaboration and innovation.    Tune in to discover how Postgres is redefining AI databases, why Timescale's tools are a game-changer for developers, and what the future holds for AI innovation in the database space.   Don't forget to like, subscribe, and hit the notification bell for more AI insights!      Stay Updated: Craig Smith Twitter: https://twitter.com/craigss Eye on A.I. Twitter: https://twitter.com/EyeOn_AI (00:00) Introduction to Avthar and Timescale (02:35) The origins of Timescale and TimescaleDB (05:06) What makes Postgres unique and reliable (07:17) Open-source philosophy at Timescale (12:04) Timescale's early focus on IoT and time series data (16:17) Applications in finance, crypto, and IoT (19:03) Postgres in AI: From RAG to semantic search (22:00) Overcoming scalability challenges with PGVector Scale (24:33) PGAI Vectorizer: Managing embeddings seamlessly (28:09) The PGAI suite: Tools for AI developers (30:33) Vectorization explained: Foundations of AI search (32:24) LLM integration within Postgres (35:26) Natural language interfaces and database workflows (38:11) Structured and unstructured data in Postgres (41:17) Postgres for everything: Simplifying complexity (44:52) Timescale's accessibility for startups and enterprises (47:46) The power of open source in AI 

Gordon MacIntyre-Kemp is our guest for the second episode in our new series of podcasts on the theme of A National Conversation for Scotland.   Gordon is CEO of campaigning organisation Believe in Scotland and he joined Indypodcasters Marlene and Fiona in the studio to talk about ambitious plans for a Scottish Citizens' Convention. Topics covered include: 00:00:27   What is a Citizens' Convention? 00:06:16   Timescale and other Challenges 00:09:28   Not an Indy Trojan horse 00:13:02   Not a Citizens' Assembly 00:16:17   Who runs the Indy Movement? 00:19:45   A Broader Conversation 00:24:00   A Deeper Conversation 00:33:14   Political Reactions 00:37:12   Trusting the Trustees 00:41:58    Creating solutions?     00:49:00     Holyrood 2026   You can find Believe in Scotland's proposal paper here: https://www.believeinscotland.org/delivering_independence_via_a_new_style_citizens_convention/ Coming up:  17th August: Campaign Day in Inverness                      21st August:  Scottish Independence Congress meeting                      18th September: 7pm Rally at Holyrood   You can find out more about Believe in Scotland events here: https://www.believeinscotland.org/events   The Scottish Independence Podcasts team produce a NEW podcast episode every Friday search for Scottish Independence Podcasts wherever you get your podcasts.  Remember to like and subscribe! Buy us a coffee: https://ko-fi.com/scottishindependencepodcasts You can also nominate us as your good cause on Easyfundraising.org.uk Contact Us: indypodcasters@gmail.com  Visit our website https://scottishindypod.scot for blogposts, newsletter signup and more episodes Subscribe to our Youtube channel @scottishindypodExtra for more of our video footage and clips Music: Inspired by Kevin MacLeod       

Nikolay and Michael discuss compression in Postgres — what's available natively, newer algorithms in recent versions, and several extensions with compression features. Here are some links to things they mentioned:wal_compression https://www.postgresql.org/docs/current/runtime-config-wal.html#GUC-WAL-COMPRESSIONOur episode on WAL and checkpoint tuning https://postgres.fm/episodes/wal-and-checkpoint-tuningSynthetic wal_compression and streaming replication wal size test https://gitlab.com/postgres-ai/postgresql-consulting/tests-and-benchmarks/-/issues/11default_toast_compression https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-DEFAULT-TOAST-COMPRESSION ZFS https://en.wikipedia.org/wiki/ZFSOur episode on TOAST https://postgres.fm/episodes/toastOn compression of everything in Postgres (talk by Andrey Borodin) https://learn.microsoft.com/en-us/shows/cituscon-an-event-for-postgres-2023/on-compression-of-everything-in-postgres-citus-con-2023cstore_fdw https://citusdata.github.io/cstore_fdw/Using Hydra columnar https://columnar.docs.hydra.so/concepts/using-hydra-columnarAbout compression in Timescale https://docs.timescale.com/use-timescale/latest/compression/about-compression/pg_tier https://github.com/tembo-io/pg_tierpgBackRest https://pgbackrest.org/WAL-G https://github.com/wal-g/wal-gpg_dump https://www.postgresql.org/docs/current/app-pgdump.htmlpg_dump compression specifications in PostgreSQL 16 (article by Pablo Glob from Cybertec) https://www.cybertec-postgresql.com/en/pg_dump-compression-specifications-postgresql-16/Our episode on pgvector (with Jonathan Katz) https://postgres.fm/episodes/pgvector ~~~What did you like or not like? What should we discuss next time? Let us know via a YouTube comment, on social media, or by commenting on our Google doc!~~~Postgres FM is produced by:Michael Christofides, founder of pgMustardNikolay Samokhvalov, founder of Postgres.aiWith special thanks to:Jessie Draws for the elephant artwork 

Ajay Kulkarni and Mike Freedman are the co-founders of Timescale, a startup that provides an enhanced version of PostgreSQL optimized for time-series analytics, AI applications, and scalable relational workloads. Subscribe to the Gradient Flow Newsletter:  https://gradientflow.substack.com/Subscribe: Apple • Spotify • Overcast • Pocket Casts • AntennaPod • Podcast Addict • Amazon •  RSS.Detailed show notes can be found on The Data Exchange web site.

Michael J. Freedman, the Robert E. Kahn Professor in the Computer Science Department at Princeton University, as well as the co-founder and CTO of Timescale, spoke with SE Radio host Gavin Henry about TimescaleDB. They revisit what time series data means in 2024, the history of TimescaleDB, how it integrates with PostgreSQL, and they take the listeners through a complete setup. Freedman discusses the types of data well-suited for a timeseries database, the types of sectors that have these requirements, why PostgreSQL is the best, Pg callbacks, Pg hooks, C programming, Rust, their open source contributions and projects, data volumes, column-data, indexes, backups, why it is common to have one table for your timeseries data, when not to use timescaledb, IoT data formats, Pg indexes, how Pg works without timescaledb, sharding, and how to manage your upgrades if not using Timescale Cloud. Brought to you by IEEE Computer Society and IEEE Software magazine.

Nikolay is joined by Mat Arye and John Pruitt, from Timescale, to discuss their new extension pgvectorscale and high-performance vector search in Postgres more generally. Main links:https://github.com/timescale/pgvectorscalehttps://www.timescale.com/blog/pgvector-vs-pineconehttps://postgres.fm/people/matvey-aryehttps://postgres.fm/people/john-pruitt~~~What did you like or not like? What should we discuss next time? Let us know via a YouTube comment, on social media, or by commenting on our Google doc!~~~Postgres FM is produced by:Nikolay Samokhvalov, founder of Postgres.aiMichael Christofides, founder of pgMustardWith special thanks to:Jessie Draws for the elephant artwork 

In this week's edition of the Weekly Investment Trust Podcast, Jonathan Davis, editor of the Investment Trusts Handbook, speaks to James Carthew, director of QuotedData, and Baroness Ros Altmann CBE about her recent Private Members Bill to address the cost disclosure issue in investment trusts. We are grateful for the support of J.P. Morgan Asset Management, which enables us to keep the podcast free. Section Timestamps: 00:39 - This week's guests 01:21 - Money Makers Circle 02:10 - Review of the week 04:56 - Summary of results 06:08 - The Investment Trusts Handbook 2024 07:30 - Q&A with James Carthew 07:39 - Market developments 10:36 - Discussing individual trusts 27:40 - Selected results this week 32:49 - Prospects for a continuing Santa Rally 35:08 - Q&A with Baroness Altmann CBE 35:27 - The Private Members' Bill 39:32 - What happens next? 45:27 - Timescale for a resolution 47:53 - Views of the AIC 50:23 - Transparency and accuracy in disclosure 57:40 - Impact of cost disclosure on derating 59:45 - Close Trusts mentioned this week (with tickers): J.P.Morgan Japanese (JFJ), Personal Assets Trust (PNL), Monks Investment Trust (MNKS), Templeton Emerging Markets (TEM), Biopharma Credit (BPCR), VinaCapital Vietnam Opportunity Fund (VOF), Picton Property Income (PCTN), European Opportunities Trust (EOT), Residential Secure Income (RESI), Ecofin US Renewables (RNEW), Barings Emerging EMEA Opportunities (BEMO), Finsbury Growth and Income (FGT), Lindsell Train Investment Trust (LTI), BlackRock Frontiers Investment Trust (BRFI), Tritax Eurobox (EBOX), Lowland (LWI), Chrysalis (CHRY). If you enjoy the weekly podcast, you may also find value in joining The Money Makers circle. This is a membership scheme that offers listeners to the podcast an opportunity, in return for a modest monthly or annual subscription, to receive additional premium content, including interviews, performance data, market/portfolio reviews and regular extracts from the editor's notebook. This week, as well as the regular features, the Circle features a profile of BlackRock Greater Europe (BRGE). Future profiles coming soon include VinaCapital Vietnam Opportunity (VOF) and J.P.Morgan UK Smaller Companies (JMI). For more information about the Money Makers circle, please visit money-makers.co/membership-join. Membership helps to cover the cost of producing the weekly investment trust podcast, which will continue to be free. We are very grateful for your continued support and the enthusiastic response to our nearly 190 podcasts since launch. You can find more information, including relevant disclosures, at www.money-makers.co. Please note that this podcast is provided for educational purposes only and nothing you hear should be considered as investment advice. Our podcasts are also available on the Association of Investment Companies website, www.theaic.co.uk. Produced by Ben Gamblin.

Nikolay and Michael discuss companion databases — when and why you might want to add another database management system to your stack (or not), and some specifics for analytics, timeseries, search, and vectors.  Here are some links to things they mentioned:Heap were using Postgres + Citus for analytics as of 2022 https://www.heap.io/blog/juggling-state-machines-incident-response-and-data-soup-a-glimpse-into-heaps-engineering-culture Heap recently moved their core analytics to SingleStore (we only spotted this after recording

QTtext} {font:Tahoma} {plain} {size:20} {timeScale:30} {width:160} {height:32} {timestamps:absolute} {language:0} [00:00:30.13] With his staccato speech and pixelated visage became an unlikely hero, [00:00:34.21] [00:00:34.21] a symbol of resistance against the tide of soulless mega corporations. [00:00:38.20] [00:00:38.21] But let's not get ahead of ourselves. [00:00:41.05] [00:00:41.06] Now, [00:00:41.18] [00:00:41.18] as we delve into some intriguing tidbits and random facts about the psychology, [00:00:45.19] [00:00:45.20] the mumbling yelling, [00:00:47.17] [00:00:47.17] almost non singing. [00:00:49.12] [00:00:49.13] That is the most memorable part. [00:00:51.13] [00:00:52.10] Well, [00:00:52.15] [00:00:52.16] that and the fact that the band successfully recorded a one second song where they [00:00:57.16] [00:00:57.16] sing the meaningful lyrics of you suffer. [00:01:00.15] [00:01:00.15] But why [00:01:01.00] [00:01:16.04] full stage play in which they were consistently acting for those eight days straight, [00:01:21.01] [00:01:21.02] almost 24 hours a day. [00:01:22.12] [00:01:22.12] However, [00:01:22.19] [00:01:22.20] despite the hardship and the unorthodox filming methods, [00:01:25.07] [00:01:25.08] as we all know, [00:01:26.02] [00:01:26.03] the film ended up being a tremendous success, [00:01:27.23] [00:01:27.24] the result of having the actors themselves film the content that they were. [00:01:31.12] --- Support this podcast: https://podcasters.spotify.com/pod/show/tadpole-slamp/support

Implantar banco de dados em Kubernetes é desafiador, mas possível e cada vez mais comum. Trabalhando há mais de 17 anos com banco de dados, o Sebastian Webber, Senior Software Engineer na Timescale, vem ao Kubicast para contar como foi essa descoberta e como segue sua saga para convencer as pessoas de que “tem que usar banco de dados em Kubernetes!”.Nessa conversa, também falamos de casos de fracasso com banco de dados, operadores de banco para Kubernetes e como convencer na “linguagem do lucro” sobre a importância de investir em infra. Links do episódio:Supercomputer Fugaku: https://www.fujitsu.com/global/about/innovation/fugaku/Meetup com o Somatório: https://www.youtube.com/watch?v=aAiqLwAdYvQOperadores de banco pra K8s: https://github.com/zalando/postgres-operatorhttps://stackgres.io/https://github.com/CrunchyData/postgres-operatorRecomendações do programa:Person of Interest - série  Barbie - filme Oppenheimer - filmeO Kubicast é uma produção da Getup, empresa especialista em Kubernetes e projetos open source para Kubernetes. Os episódios do podcast estão em getup.io/kubicast, nas principais plataformas de áudio digital e no YouTube.com/@getupcloud.

Nikolay and Michael discuss sharding Postgres — what it means, why and when it's needed, and the available options right now.  Here are some links to some things they mentioned:PGSQL Friday monthly blogging event https://www.pgsqlphriday.com/Did “sharding” come from Ultima Online? https://news.ycombinator.com/item?id=23438399 Our episode on partitioning: https://postgres.fm/episodes/partitioningVitess https://vitess.io/Citus https://www.citusdata.com/ Lessons learned from sharding Postgres (Notion 2021) https://www.notion.so/blog/sharding-postgres-at-notion The Great Re-shard (Notion 2023) https://www.notion.so/blog/the-great-re-shard The growing pains of database architecture (Figma 2023) https://www.figma.com/blog/how-figma-scaled-to-multiple-databases/Timescale multi-node https://docs.timescale.com/self-hosted/latest/multinode-timescaledb/about-multinode/ PgCat https://github.com/postgresml/pgcat SPQR https://github.com/pg-sharding/spqr PL/Proxy https://plproxy.github.io/ Sharding GitLab by top-level namespace https://about.gitlab.com/handbook/engineering/development/enablement/data_stores/database/doc/root-namespace-sharding.html Loose foreign keys (GitLab) https://docs.gitlab.com/ee/development/database/loose_foreign_keys.html ~~~What did you like or not like? What should we discuss next time? Let us know via a YouTube comment, on social media, or by commenting on our Google doc!~~~Postgres FM is brought to you by:Nikolay Samokhvalov, founder of Postgres.aiMichael Christofides, founder of pgMustardWith special thanks to:Jessie Draws for the amazing artwork 

Join us as we try to help you understand how the Fantastic Four, Spider-Man, and more are still fighting crime 60-80 years later and they don't look like they aged more than 10 years. --- Send in a voice message: https://podcasters.spotify.com/pod/show/web-heads/message Support this podcast: https://podcasters.spotify.com/pod/show/web-heads/support

Link to bioRxiv paper: http://biorxiv.org/cgi/content/short/2023.04.18.537377v1?rss=1 Authors: Xiao, K., Li, Y., Chitwood, R. A., Magee, J. C. Abstract: Behavioral timescale synaptic plasticity (BTSP) is a type of non-Hebbian synaptic plasticity reported to underlie place field formation in the hippocampal CA1 neurons. Despite this important function, the molecular mechanisms underlying BTSP are poorly understood. The Calcium-calmodulin-dependent protein kinase II (CaMKII) is activated by synaptic transmission-mediated calcium influx and its subsequent phosphorylation is central to synaptic plasticity. Because the activity of CaMKII is known to outlast the event triggering phosphorylation, we hypothesized it could be involved in the extended timescale of the BTSP process. To examine the role of CaMKII in BTSP, we performed whole-cell in-vivo and in-vitro recordings in CA1 pyramidal neurons from mice engineered to have a point mutation at the autophosphorylation site (T286A) causing accelerated signaling kinetics. Here we demonstrate a profound deficit in synaptic plasticity, strongly suggesting that CaMKII signaling is required for BTSP. This study elucidates part of the molecular mechanism of BTSP and provides insight into the function of CaMKII in place cell formation and ultimately learning and memory. Copy rights belong to original authors. Visit the link for more info Podcast created by Paper Player, LLC

Ajay Kulkarni is the CEO and Co-Founder of Timescale, creators of the industry-leading relational database for time series, built on the standards of PostgreSQL and SQL. With a focus on time-series data, his extensive experience has helped shape Timescale into a company dedicated to serving developers globally, enabling them to build the next wave of computing.  Timescale is backed by Benchmark, NEA, Redpoint, Tiger Global, Icon Ventures, and Two Sigma Ventures.Connect with Behind Company Lines and HireOtter Website Facebook Twitter LinkedIn:Behind Company LinesHireOtter Instagram Buzzsprout

Nikolay and Michael discuss table partitioning — what it is, why and when it's helpful, and some considerations for your partition key. Here are links to a few things we mentioned: Partitioning docspg_partmanIndex maintenance episode Timescale partitioningpg_cronXtreme PostgreSQL (talk by Christophe Pettus)Database Antipatterns (also by Christophe, slides 46-49)Understanding an outage (blog post by Duffel)~~~What did you like or not like? What should we discuss next time? Let us know on social media, or by commenting on our Google doc.If you would like to share this episode, here's a good link (and thank you!)~~~Postgres FM is brought to you by:Nikolay Samokhvalov, founder of Postgres.aiMichael Christofides, founder of pgMustardWith special thanks to:Jessie Draws for the amazing artwork 

News covers the EEF election results, a new Livebook 0.9 release, Docker reverses directions, how Github spilled the secret beans, full text search with a new Haystack lib, how intentionally vulnerable Phoenix apps are educational, the timescale hex package grows up a little, and more! Show Notes online - http://podcast.thinkingelixir.com/145 (http://podcast.thinkingelixir.com/145) Elixir Community News - https://erlef.org/blog/eef/election-2023-results (https://erlef.org/blog/eef/election-2023-results?utm_source=thinkingelixir&utm_medium=shownotes) – New Erlang Ecosystem Foundation members - https://news.livebook.dev/announcing-livebook-0.9-2tiuLC (https://news.livebook.dev/announcing-livebook-0.9-2tiuLC?utm_source=thinkingelixir&utm_medium=shownotes) – Livebook 0.9 was released and has a short accompanying blog post. - https://www.docker.com/blog/no-longer-sunsetting-the-free-team-plan/ (https://www.docker.com/blog/no-longer-sunsetting-the-free-team-plan/?utm_source=thinkingelixir&utm_medium=shownotes) – Docker is no longer sunsetting the Free Team Plan - https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/ (https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/?utm_source=thinkingelixir&utm_medium=shownotes) – GitHub SSH key leaked and reset - https://elixirstream.dev/gendiff (https://elixirstream.dev/gendiff?utm_source=thinkingelixir&utm_medium=shownotes) – ElixirStream diff generator updated with awareness for Credo. - https://github.com/zestcreative/elixirstream/commit/3c4278469201c45f7d794aaa6343f0fe18df4cda (https://github.com/zestcreative/elixirstream/commit/3c4278469201c45f7d794aaa6343f0fe18df4cda?utm_source=thinkingelixir&utm_medium=shownotes) – What's involved in getting a new project diff added - https://culttt.com/2023/03/22/building-a-full-text-search-engine-in-elixir (https://culttt.com/2023/03/22/building-a-full-text-search-engine-in-elixir?utm_source=thinkingelixir&utm_medium=shownotes) – New full-text search library called Haystack from Philip Brown - https://github.com/elixir-haystack/haystack (https://github.com/elixir-haystack/haystack?utm_source=thinkingelixir&utm_medium=shownotes) – Haystack project on Github - https://github.com/heywhy/ex_elasticlunr (https://github.com/heywhy/ex_elasticlunr?utm_source=thinkingelixir&utm_medium=shownotes) – Comparable search library ElasticLunr - https://twitter.com/paraxialio/status/1638161831373029377 (https://twitter.com/paraxialio/status/1638161831373029377?utm_source=thinkingelixir&utm_medium=shownotes) – Paraxial released an intentionally vulnerable project for people to play with and exploit - https://paraxial.io/blog/potion-shop (https://paraxial.io/blog/potion-shop?utm_source=thinkingelixir&utm_medium=shownotes) – Vulnerable "Potion Shop" project - https://owasp.org/www-project-juice-shop/ (https://owasp.org/www-project-juice-shop/?utm_source=thinkingelixir&utm_medium=shownotes) – OWASP's "Juice Shop" vulnerable project - https://twitter.com/sm_debenedetto/status/1638496777463648260 (https://twitter.com/sm_debenedetto/status/1638496777463648260?utm_source=thinkingelixir&utm_medium=shownotes) – The book "Programming Phoenix LiveView" by Bruce Tate and Sophie DeBennedetto released a new update. - https://pragprog.com/titles/liveview/programming-phoenix-liveview/ (https://pragprog.com/titles/liveview/programming-phoenix-liveview/?utm_source=thinkingelixir&utm_medium=shownotes) – The book on PragProg - https://twitter.com/germsvel/status/1638158470317834246 (https://twitter.com/germsvel/status/1638158470317834246?utm_source=thinkingelixir&utm_medium=shownotes) – Tip for testing function components by rendering them to HTML - https://twitter.com/germsvel/status/1640696116017614850 (https://twitter.com/germsvel/status/1640696116017614850?utm_source=thinkingelixir&utm_medium=shownotes) – Tip for paginating as an infinite scroll with streams - https://hex.pm/packages/timescale (https://hex.pm/packages/timescale?utm_source=thinkingelixir&utm_medium=shownotes) – Timescale library published a pseudo-stable version, 0.1.0. (no longer alpha) - https://podcast.thinkingelixir.com/129 (https://podcast.thinkingelixir.com/129?utm_source=thinkingelixir&utm_medium=shownotes) – Our interview with Dave Lucia about Timescale - https://hexdocs.pm/ecto_range/EctoRange.html (https://hexdocs.pm/ecto_range/EctoRange.html?utm_source=thinkingelixir&utm_medium=shownotes) – New Ecto library about storing Ecto Ranges. Provides Ecto types for Postgres about storing a time range, date range, datetime ranges, and integer ranges, and supports indeterminate bounds. Do you have some Elixir news to share? Tell us at @ThinkingElixir (https://twitter.com/ThinkingElixir) or email at show@thinkingelixir.com (mailto:show@thinkingelixir.com) Find us online - Message the show - @ThinkingElixir (https://twitter.com/ThinkingElixir) - Message the show on Fediverse - @ThinkingElixir@genserver.social (https://genserver.social/ThinkingElixir) - Email the show - show@thinkingelixir.com (mailto:show@thinkingelixir.com) - Mark Ericksen - @brainlid (https://twitter.com/brainlid) - Mark Ericksen on Fediverse - @brainlid@genserver.social (https://genserver.social/brainlid) - David Bernheisel - @bernheisel (https://twitter.com/bernheisel) - David Bernheisel on Fediverse - @dbern@genserver.social (https://genserver.social/dbern) - Cade Ward - @cadebward (https://twitter.com/cadebward) - Cade Ward on Fediverse - @cadebward@genserver.social (https://genserver.social/cadebward)

Highlights from this week's conversation include:David's background and journey to Timescale (2:12)What are time series databases? (14:13)How Timescale would have impacted David's trajectory early in his career (17:51)Innovation in postgreSQL (21:02)Why does Timescale build their timeseries databases differently? (27:08)The challenges of building a new database on top of an old software (32:22)Writing outside of SQL and Timescale's secret sauce (37:47)The importance of the developer experience in Timescale (54:08)How does someone know when they need to implement time series functionality (56:51)Final thoughts and takeaways (1:04:57)The Data Stack Show is a weekly podcast powered by RudderStack, the CDP for developers. Each week we'll talk to data engineers, analysts, and data scientists about their experience around building and maintaining data infrastructure, delivering data and data products, and driving better outcomes across their businesses with data.RudderStack helps businesses make the most out of their customer data while ensuring data privacy and security. To learn more about RudderStack visit rudderstack.com.

In this bonus episode, Eric and Kostas preview their upcoming conversation with David Kohn of Timescale.

In today's episode of Category Visionaries, we speak with Ajay Kulkarni, CEO of Timescale, an open source time series SQL database that's raised over $180 Million in funding, about why, as computers get more powerful and data storage gets cheaper, the future of our digital transformation lies in better databases. With a market offering optimized for data intensive applications which capture large volumes of information for use in enterprise decision making, but faster, cheaper and better than current market offerings, Timescale is set to make a massive impact on the way data affects all of our daily lives. We also speak about how perseverance kept Ajay in the startup space even after less than successful attempts at first, why he believes the success in any business is the grind, the pros and cons of starting a business during tough economic times, and how Timescale's early PLG strategy was built on the strength of their community. Topics Discussed: Ajay's first forays as a founder, and why he feels he learned a lot but never quite got the formula right until now Why Ajay believes that when it comes to business success, there's nothing more essential than the grind The competitive aspect of a commercial enterprise, and why every founder needs a bit of faith in themselves and their idea How constant development in the data collection and storage capacity of our devices makes better databases and essential tool for the economy of tomorrow Why Timescale's faster, cheaper, better model for data intensive applications is leaving the competition behind How building a community helped give Timescale's PLG strategy a head start   Favorite book:  The Alchemist: A Fable About Following Your Dream

Nikolay and Michael discuss TOAST (The Oversized-Attribute Storage Technique) — what it is, how it works, and some general things to be aware of. Here are links to a few things we mentioned: TOAST docsTOAST wikiHussein Nasser on rows per page (Twitter)Toasting in action (dbi services blog)Interview with Peter Zaitsev (Postgres TV)Building columnar compression in a row-oriented database (Timescale blog post)The Surprising Impact of Medium-Size Texts on PostgreSQL Performance (blog post by Haki Benita)PostgreSQL at Scale: Saving Space Basically for Free (blog post by Braintree on column Tetris)postgres_dba alignment padding query ------------------------What did you like or not like? What should we discuss next time? Let us know by tweeting us on @samokhvalov / @michristofides / @PostgresFM, or by commenting on our Google doc.If you would like to share this episode, here's a good link (and thank you!)Postgres FM is brought to you by:Nikolay Samokhvalov, founder of Postgres.aiMichael Christofides, founder of pgMustardWith special thanks to:Jessie Draws for the amazing artwork 

This week on WTFolklore, we read The Barrel Bung, A Swedish tale about jump scares and glory holes, and we peppered in a light dusting of Satanic Panic at the end, for flavor.Suggested talking points: The Timescale of Omens, Jumpscare Jenny, The One Thing a Bat Cannot Tolerate, BURN THE BUNG, Son of Pikachu, Down the Satanic Panic HoleIf you'd like to support Carman's artistic endeavors, visit: https://www.patreon.com/carmandaartsthingsIf you like our show, find us online to help spread the word! Follow us on Twitter, Facebook, and Youtube. Support us on Patreon to help the show grow at www.patreon.com/wtfolklore. You can find merchandise and information about the show at www.wtfolklorepodcast.com.

Guillaume et Arnaud discutent de tech en cette nouvelle année 2023. GraalVM dans OpenJDK, Rust, Webassembly, containers. postgres, ChatGPT, le rôle de l'architecte et la ribambelle de rétrospective 2022. Enregistré le 13 janvier 2023 Téléchargement de l'épisode LesCastCodeurs-Episode–290.mp3 News Langages OpenJDK propose projet Galahad : pour fusionner dans OpenJDK certaines parties de GraalVM community edition https://www.infoq.com/news/2022/12/openjdk-galahad-Dec22/ https://www.infoq.com/articles/graalvm-java-compilers-openjdk/ Alex Snaps partage un article sur Rust pour le développeur Java https://wcgw.dev/posts/2023/rusty-java-intro/ Google a sorti sa formation interne sur Rust en libre accès https://google.github.io/comprehensive-rcust/ Paul King du projet Apache Groovy partage sa rétrospective de l'année 2022 https://blogs.apache.org/groovy/entry/apache-groovy–2022-year-in Webassembly pour le developpeur Java https://www.javaadvent.com/2022/12/webassembly-for-the-java-geek.html Un article assez critique sur TypeScript https://dev.to/wiseai/17-compelling-reasons-to-start-ditching-typescript-now–249b On voit souvent des articles plutôt positif sur TypeScript, mais est-ce que tout est tout rose tout le temps, pas forcément ! L'article cite 17 problèmes avec TypeScript, dont la courbe d'apprentissage, la baisse de productivité, la verbosité des types, le manque de flexibilité, le fait que ce n'est pas vraiment un sur-ensemble de JavaScript, la lenteur du temps de compilation… basé sur son talk sur le même thème qu'il a déjà présenté à Devoxx Maroc et Belgique Alex a également écrit une deuxième partie faisant suite à son article, dans lequel il parle un peu plus d'ownership, de borrowing, du trait Drop, etc. (càd sur la gestion mémoire) https://wcgw.dev/posts/2023/rusty-java–2/ Librairies Sortie du Micronaut 3.8 https://micronaut.io/2022/12/27/micronaut-framework–3–8–0-released/ support de GraalVM 22.3.0 possibilité d'annoter les records avec @RequestBean (pour binder les paramètres de requête et autre, aux paramètres de la méthode du controleur) amélioration du CorsFilter pour éviter certaines attaques également des améliorations sur le support de CRaC (Coordinated Restore at Checkpoint) et plein d'autres upgrades de versions, nouveaux plugins, et améliorations mineures Swing n'est pas mort ! Un nouveau DSL Java open source pour Swing dénommé Sierra, pour faciliter la création d'interfaces graphiques Swing https://github.com/HTTP-RPC/Sierra Infrastructure Comprendre root dans et en dehors des containers https://www.redhat.com/en/blog/understanding-root-inside-and-outside-container un article pas recent mais utile c'est quoi un container rootless on peut etre root et lancer le moteur de container on peut etre root dans le container lui meme quand on run en root le moteur, l'utilisateur exterieur et interieur sont mappés (meme # d'UID) ; par contre en non root, le UID de l'utilisateur du container est mappé sur un nouvel UID c'est top car les utilisateurs dedans et dehors ne sont pas mappés donc moins de risque en cas de sortie de bac a sable (sandbox escape) c'est le cas pour podman mais pour docker il y a un ajout: docker a un démon (root ou pas) et une CLI qui appelle ce demon (root ou pas), ce qui importe c'est le demon pour les risques de sécu l'idéal c'est de tourner non root le moteur et dans le container (meme si encore beaucoup d'images s'attendent a être root les folles) Cloud Kubernetes 1.26 avec notamment une de corrélation de l'hébergement de la Registry par Google https://www.infoq.com/news/2022/12/kubernetes–1–26/?utm_campaign=infoq_content&utm_source=twitter&utm_medium=feed&utm_term=Devops Web Evan You, le créateur de Vue.js revient sur l'année 2022 https://blog.vuejs.org/posts/2022-year-in-review.html C'est la grande migration de Vue 2 vers Vue 3 Migration de l'API Composition de Vue 3 vers l'API Options de Vue 2 (mais supporté encore en 3) La documentation de Vue propose Vue 3 par défaut depuis février Pendant la phase de transition, gros focus sur l'outillage et l'expérience développeur L'écosystème a bien adopté Vue 3 et continue de le faire au fur et à mesure Pour 2023, espère faire plus de releases mineures régulières, et travail sur le “vapor mode” qui propose une stratégie de compilation plus rapide Data Un article de Stephan Schmidt qui suggère d'utiliser PostgreSQL… pour tout ! https://www.amazingcto.com/postgres-for-everything/ pour du caching à la place de REDIS comme une queue de messages pour stocker des documents JSON au lieu de MongoDB pour faire des requêtes géo-spatiales pour le full-text search à la place d'ElasticSearch pour générer du JSON directement en base comme stockage / adaptateur pour GraphQL ou pour Timescale (base de données time-series) Outillage ChatGPT en action sur le design d'un nouveau langage de programmation https://judehunter.dev/blog/chatgpt-helped-me-design-a-brand-new-programming-language ChatGPT, on lui attribue plus de magie qu'il n'en a https://arxiv.org/pdf/2212.03551.pdf Github rajoute le scan des secrets dans vos répos publics aussi https://github.blog/2022–12–15-leaked-a-secret-check-your-github-alerts-for-free/ ce n'est plus seulement pour les organisations des entreprises aussi accessible pour les répos publics permet d'éviter de leaker des clés d'API et autre Les nouveautés de Java sur Visual Studio Code https://foojay.io/today/java-on-visual-studio-code-update-december–2022/ amélioration visuelles pour les extensions Spring Boot et aussi pour la visualisation de la mémoire utilisée complétion “post-fix” comme dans IntelliJ plus de raccourcis pour générer du code support de Lombok intégré support de l'annotation processing de Gradle meilleure visualisation des erreurs de build 2 millions de développeurs utilisent Visual Studio Code pour Java Encore un guide pour sortir de Vi https://thevaluable.dev/vim-advanced/ Le client HTTP de IntelliJ peut maintenant être utilisé en ligne de commande et dans un environnement d'intégration continue https://blog.jetbrains.com/idea/2022/12/http-client-cli-run-requests-and-tests-on-ci/ Architecture L'évolution du rôle de l'architecte https://www.infoq.com/articles/architecture-architecting-role/ Le (très long) rapport des tendances 2023 par Didier Girard et Olivier Rafal https://www.linkedin.com/pulse/rapport-tendances–2023-didier-girard/?trackingId=wu9pJ4wNQAOKjh11R2UyjA%3D%3D un prisme tech/orga/culture pour préparer l'entreprise aux enjeux un prisme produits/plateformes/data pour structurer notre approche d'un SI moderne. couvre des tonnes de sujets de l'intelligence artificielle, les données, le cloud, le web1/2/3, mais aussi l'organisation des équipes, les rôles, etc. Loi, société et organisation Twitter n'apprécie guère Mastodon, et bride les tweets avec des liens vers Mastodon. La liberté d'expression façon Elon Musk ! https://twitter.com/bluxte/status/1603656787097534464 Statement de Mastodon sur le fait que Twitter bannit les liens vers Mastodon https://blog.joinmastodon.org/2022/12/twitter-suspends-mastodon-account-prevents-sharing-links/ Et finalement Twitter est revenu en arrière sur son changement des conditions d'utilisation Dans la famille “les informaticiens ont des supers passions”, je voudrais Cédric Champeau, qui nous fait une magnifique rétrospective de ces clichés d'astrophotographie https://melix.github.io/blog//2022/12/astrophoto–2022.html Conférences La liste des conférences provenant de Developers Conferences Agenda/List par Aurélie Vache et contributeurs : 19 janvier 2023 : Archilocus - Bordeaux (France) 19–20 janvier 2023 : Touraine Tech - Tours (France) 25–28 janvier 2023 : SnowCamp - Grenoble (France) 31 janvier 2023 : Duck Conf - Paris (France) 2 février 2023 : Very Tech Trip - Paris (France) 2 février 2023 : AgiLeMans - Le Mans (France) 9–11 février 2023 : World AI Cannes Festival - Cannes (France) 16–19 février 2023 : PyConFR - Bordeaux (France) 7 mars 2023 : Kubernetes Community Days France - Paris (France) 23–24 mars 2023 : SymfonyLive Paris - Paris (France) 23–24 mars 2023 : Agile Niort - Niort (France) 1–2 avril 2023 : JdLL - Lyon 3e (France) 5–7 avril 2023 : FIC - Lille Grand Palais (France) 12–14 avril 2023 : Devoxx France - Paris (France) 20–21 avril 2023 : Toulouse Hacking Convention 2023 - Toulouse (France) 4–6 mai 2023 : Devoxx Greece - Athens (Greece) 10–12 mai 2023 : Devoxx UK - London (UK) 12 mai 2023 : AFUP Day - lle & Lyon (France) 25–26 mai 2023 : Newcrafts Paris - Paris (France) 26 mai 2023 : Devfest Lille - Lille (France) 27 mai 2023 : Polycloud - Montpellier (France) 7 juin 2023 : Serverless Days Paris - Paris (France) 15–16 juin 2023 : Le Camping des Speakers - Baden (France) 29–30 juin 2023 : Sunny Tech - Montpellier (France) 19 septembre 2023 : Salon de la Data Nantes - Nantes (France) & Online 21–22 septembre 2023 : API Platform Conference - Lille (France) & Online 2–6 octobre 2023 : Devoxx Belgium - Antwerp (Belgium) 12 octobre 2023 : Cloud Nord - Lille (France) 12–13 octobre 2023 : Volcamp 2023 - Clermont-Ferrand (France) 6–7 décembre 2023 : Open Source Experience - Paris (France) Nous contacter Pour réagir à cet épisode, venez discuter sur le groupe Google https://groups.google.com/group/lescastcodeurs Contactez-nous via twitter https://twitter.com/lescastcodeurs Faire un crowdcast ou une crowdquestion Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Tous les épisodes et toutes les infos sur https://lescastcodeurs.com/

Link to bioRxiv paper: http://biorxiv.org/cgi/content/short/2023.01.06.523055v1?rss=1 Authors: Mano, O., Choi, M., Tanaka, R., Creamer, M. S., Castelo Branco Matos, N., Shomar, J., Badwan, B. A., Clandinin, T. R., Clark, D. A. Abstract: Locomotor movements cause visual images to be displaced across the eye, a retinal slip that is counteracted by stabilizing reflexes in many animals. In insects, optomotor turning causes the animal to turn in the direction of rotating visual stimuli, thereby reducing retinal slip and stabilizing trajectories through the world. This behavior has formed the basis for extensive dissections of motion vision. Here, we report that under certain stimulus conditions, two Drosophila species, including the widely studied D. melanogaster, can suppress and even reverse the optomotor turning response over several seconds. Such 'anti-directional turning' is most strongly evoked by long-lasting, high-contrast, slow-moving visual stimuli that are distinct from those that promote syn-directional optomotor turning. Anti-directional turning, like the syn-directional optomotor response, requires the local motion detecting neurons T4 and T5; a subset of lobula plate tangential cells, CH cells, show involvement in these responses. Imaging from a variety of direction-selective cells in the lobula plate shows no evidence of dynamics that match the behavior, suggesting that the observed inversion in turning direction emerges downstream of the lobula plate. Further, anti-directional turning declines with age and exposure to light. These results show that Drosophila optomotor turning behaviors contain rich, stimulus-dependent dynamics that are inconsistent with simple reflexive stabilization responses. Copy rights belong to original authors. Visit the link for more info Podcast created by Paper Player, LLC

Link to bioRxiv paper: http://biorxiv.org/cgi/content/short/2023.01.01.522410v1?rss=1 Authors: Imani, E., Hashemi, A., Radkani, S., Egger, S. W., Moazami Goudarzi, M. Abstract: Across the cortical hierarchy, single neurons are characterized by differences in the extent to which they can sustain their firing rate over time (i.e., their "intrinsic timescale"). Previous studies have demonstrated that neurons in a given brain region mostly exhibit either short or long intrinsic timescales. In this study, we sought to identify populations of neurons that accumulate information over different timescales in the mouse brain and to characterize their functions in the context of a visual discrimination task. Thus, we separately examined the neural population dynamics of neurons with long or short intrinsic timescales across different brain regions. More specifically, we looked at the decoding performance of these neural populations aligned to different task variables (stimulus onset, movement). Taken together, our population-level findings support the hypothesis that long intrinsic timescale neurons encode abstract variables related to decision formation. Furthermore, we investigated whether there was a relationship between how well a single neuron represents the animal's choice or stimuli and their intrinsic timescale. We did not observe any significant relationship between the decoding of these task variables and a single neuron's intrinsic timescale. In summary, our findings support the idea that the long intrinsic timescale population of neurons, which appear at different levels of the cortical hierarchy, are primarily more involved in representing the decision variable. Copy rights belong to original authors. Visit the link for more info Podcast created by Paper Player, LLC

Here are links to a few things we mentioned: 1. Startups building momentumAiven raised $210m  Timescale raised $110m  Hasura raised $100m  Supabase raised $80m  Neon raised $30m Hydra  OrioleDB  2. Educational resourcesPostgres FM started

Welcome to episode 25 of More than a Refresh, where JD sits down with Ajay Kulkarni, Co-Founder and CEO @ Timescale. Listen in as they discuss the intersection of cutting edge technology and the marketplace, open source vs. open standards, and the cloud as the reinvention of the wheel.

Tracking, analyzing and visualizing time series data can add a lot of business value to a project! We met up with Dave Lucia to learn more about Timescale DB, a PostgreSQL extension that adds time series tools to our regular database. Dave also created a timescale hex package to make it easier to work with hypertables and hyperfunctions. We learn why Timescale DB makes sense over other options, how to get started with it, example use cases, helpful resources and more! Show Notes online - http://podcast.thinkingelixir.com/129 (http://podcast.thinkingelixir.com/129) Elixir Community News - https://adventofcode.com/ (https://adventofcode.com/) – Advent of Code is going on - https://gist.github.com/marpo60/bcf7dd45003adfe01b5581d03157a5de (https://gist.github.com/marpo60/bcf7dd45003adfe01b5581d03157a5de) – Marcelo Dominguez' Livebook template for working on the daily problems. - https://genserver.social/notice/AQAdGQAE5sgRL8x1g8 (https://genserver.social/notice/AQAdGQAE5sgRL8x1g8) – José Valim created a repository to share all the Livebooks he has worked on, including talks and last year's Advent of Code - https://github.com/josevalim/livebooks/ (https://github.com/josevalim/livebooks/) – José Valim's collection of shared public Livebooks - https://github.com/rosaan/advent-of-code-2022 (https://github.com/rosaan/advent-of-code-2022) – Some shared solutions - https://twitter.com/josevalim/status/1597880468032040960 (https://twitter.com/josevalim/status/1597880468032040960) – Explorer v0.4.0 is out - https://hexdocs.pm/explorer/0.4.0 (https://hexdocs.pm/explorer/0.4.0) - https://hexdocs.pm/explorer/0.4.0/Explorer.Query.html (https://hexdocs.pm/explorer/0.4.0/Explorer.Query.html) – Explorer.Query is a new API for writing expressive and performant queries - https://podcast.thinkingelixir.com/104 (https://podcast.thinkingelixir.com/104) – Chris Grainger talked about Explorer with us in episode 104 - https://tips.nerves-project.org/ (https://tips.nerves-project.org/) – Nerves website gets a new “tips” view - https://twitter.com/josevalim/status/1597943279164993537 (https://twitter.com/josevalim/status/1597943279164993537) – José Valim announced he was migrating to the genserver.social Mastadon server - https://genserver.social/josevalim (https://genserver.social/josevalim) – José's genserver.social profile - https://genserver.social/notice/AQIfjB7SQcuEwPGEAC (https://genserver.social/notice/AQIfjB7SQcuEwPGEAC) – José teased something "really big". Already released by the time you hear this. - https://genserver.social/notice/AQIlH84yjkrh856rS4 (https://genserver.social/notice/AQIlH84yjkrh856rS4) – The graphic he teased - http://codebeammexico.com/ (http://codebeammexico.com/) – Code BEAM Lite México, March 3-4 2023 in México City - https://thetinycto.com/blog/writing-a-game-using-chatgpt (https://thetinycto.com/blog/writing-a-game-using-chatgpt) – Writing an Elixir LiveView game using ChatGPT - https://thetinycto.com/gpt-game (https://thetinycto.com/gpt-game) – The generated game - https://chat.openai.com/chat (https://chat.openai.com/chat) – ChatGPT Do you have some Elixir news to share? Tell us at @ThinkingElixir (https://twitter.com/ThinkingElixir) or email at show@thinkingelixir.com (mailto:show@thinkingelixir.com) Discussion Resources - https://github.com/bitfo/timescale (https://github.com/bitfo/timescale) – Timescale and Elixir - https://www.timescale.com/ (https://www.timescale.com/) - https://docs.timescale.com/ (https://docs.timescale.com/) - https://www.bitfo.com/ (https://www.bitfo.com/) - https://defirate.com/ (https://defirate.com/) - https://www.bitcoinprice.com/ (https://www.bitcoinprice.com/) - https://ethereumprice.org/ (https://ethereumprice.org/) - https://docs.timescale.com/api/latest/hypertable/ (https://docs.timescale.com/api/latest/hypertable/) – Hypertables - https://docs.timescale.com/api/latest/hyperfunctions/ (https://docs.timescale.com/api/latest/hyperfunctions/) – Hyperfunctions - https://codebeamamerica.com/talks/accessible-time-series-data-with-timescaledb/ (https://codebeamamerica.com/talks/accessible-time-series-data-with-timescaledb/) - https://fly.io/docs/postgres/managing/enabling-timescale/ (https://fly.io/docs/postgres/managing/enabling-timescale/) - https://www.whoop.com/ (https://www.whoop.com/) – Dave's biometric watch - https://www.postgresql.org/docs/current/rules-materializedviews.html (https://www.postgresql.org/docs/current/rules-materializedviews.html) - https://www.influxdata.com/ (https://www.influxdata.com/) - https://fly.io/docs/postgres/managing/enabling-timescale/ (https://fly.io/docs/postgres/managing/enabling-timescale/) – Fly.io command to add timescale DB - fly pg config update --shared-preload-libraries timescaledb --app - https://www.crunchydata.com/ (https://www.crunchydata.com/) - https://docs.timescale.com/api/latest/hypertable/ (https://docs.timescale.com/api/latest/hypertable/) - https://docs.timescale.com/api/latest/hyperfunctions/ (https://docs.timescale.com/api/latest/hyperfunctions/) - https://docs.timescale.com/timescaledb/latest/timescaledb-edition-comparison/ (https://docs.timescale.com/timescaledb/latest/timescaledb-edition-comparison/) - https://hexdocs.pm/timescale/intro.html (https://hexdocs.pm/timescale/intro.html) - https://www.milkroad.com/ (https://www.milkroad.com/) - https://docs.google.com/presentation/d/1c2gCxfigeQNz-Z32IaLrpdxt0JYwMc6Lam_vvUND31Y/edit?usp=sharing (https://docs.google.com/presentation/d/1c2gCxfigeQNz-Z32IaLrpdxt0JYwMc6Lam_vvUND31Y/edit?usp=sharing) – Slides for Dave's Timescale talk from Code BEAM America - https://hexdocs.pm/timescale/intro.html (https://hexdocs.pm/timescale/intro.html) – Dave's “Intro to Timescale” Livebook from the Elixir Timescale docs Guest Information - https://twitter.com/davydog187 (https://twitter.com/davydog187) – on Twitter - https://github.com/davydog187/ (https://github.com/davydog187/) – on Github - https://davelucia.com/ (https://davelucia.com/) – Blog Find us online - Message the show - @ThinkingElixir (https://twitter.com/ThinkingElixir) - Message the show on Mastadon - @ThinkingElixir@genserver.social (https://genserver.social/ThinkingElixir) - Email the show - show@thinkingelixir.com (mailto:show@thinkingelixir.com) - Mark Ericksen - @brainlid (https://twitter.com/brainlid) - Mark Ericksen on Mastadon - @brainlid@genserver.social (https://genserver.social/brainlid) - David Bernheisel - @bernheisel (https://twitter.com/bernheisel) - David Bernheisel on Mastadon - @dbern@genserver.social (https://genserver.social/dbern) - Cade Ward - @cadebward (https://twitter.com/cadebward) - Cade Ward on Mastadon - @cadebward@genserver.social (https://genserver.social/cadebward)

Today we're talking to Richard Sawyer, Vice President of Engineering at Everactive; and we discuss what went into creating the world's first battery-free sensor; how these sensors are being used to measure steam from chocolate factories; and why working at a startup is like drinking from a firehose. All of this right here, right now, on the Modern CTO Podcast!  Check out more of Richard and Everactive at https://everactive.com/! In case you missed it: check out our episode with Mike Freedman, co-founder and CTO of Timescale.

Michael talks about how Timescale is addressing the need for time-series databases, the largest challenges and opportunities in databases for years to come: helping developers, businesses, and society make sense of the data that humans and their machines are generating in copious amounts. --- Send in a voice message: https://anchor.fm/bettertech/message

Apologies, Michael's audio is not great in this, we'll hopefully be back to normal next week!Here are links to a few things we mentioned: Materialized views (docs)Refresh materialized view (docs)Timescale blog postPlanetScale Boost (content warning: MySQL) Incremental Materialized Views with pg_ivm (video by Lukas Fittl) Articles on how to do your own incremental updates(?)Materialize (company) Materialize talkIncremental View Maintenance (Postgres wiki)  Implementing Incremental View Maintenance (mailing list thread) ------------------------What did you like or not like? What should we discuss next time? Let us know by tweeting us on @samokhvalov / @michristofides / @PostgresFM, or by commenting on our Google doc.If you would like to share this episode, here's a good link (and thank you!)Postgres FM is brought to you by:Nikolay Samokhvalov, founder of Postgres.aiMichael Christofides, founder of pgMustardWith special thanks to:Jessie Draws for the amazing artwork 

Timescale-dependent X-ray to UV time lags of NGC 4593 using high-intensity XMM-Newton observations with Swift and AstroSat by Max W. J. Beard et al. on Monday 21 November We present a 140ks observation of NGC 4593 with XMM-Newton providing simultaneous and continuous PN X-ray and OM UV (UVW1 2910AA) lightcurves which sample short-timescale variations better than previous observations. These observations were simultaneous with 22d of Swift X-ray and UV/optical monitoring, reported previously, and 4d of AstroSat X-ray (SXT), far (FUV 1541AA), and near (NUV 2632AA) UV allowing lag measurements between them and the highly-sampled XMM. From the XMM we find that UVW1 lags behind the X-rays by 29.5$pm$1.3ks, $sim$half the lag previously determined from the Swift monitoring. Re-examination of the textit{Swift} data reveals a bimodal lag distribution, with evidence for both the long and short lags. However if we detrend the Swift lightcurves by LOWESS filtering with a 5d width, only the shorter lag (23.8$pm$21.2ks) remains. The NUV observations, compared to PN and SXT, confirm the $sim$30ks lag found by XMM and, after 4d filtering is applied to remove the long-timescale component, the FUV shows a lag of $sim$23ks. The resultant new UVW1, FUV, and NUV lag spectrum extends to the X-ray band without requiring additional X-ray to UV lag offset, which if the UV arises from reprocessing of X-rays, implies direct illumination of the reprocessor. By referencing previous Swift and HST lag measurements, we obtain an X-ray to optical lag spectrum which agrees with a model using the KYNreverb disc-reprocessing code, assuming the accepted mass of $7.63times10^{6}M_{odot}$ and a spin approaching maximum. Previously noted lag contribution from the BLR in the Balmer and Paschen continua are still prominent. arXiv: http://arxiv.org/abs/http://arxiv.org/abs/2211.10229v1

Link to bioRxiv paper: http://biorxiv.org/cgi/content/short/2022.11.01.514668v1?rss=1 Authors: Gann, M. A., Dolfen, N., King, B. R., Robertson, E. M., Albouy, G. Abstract: Functional brain responses in hippocampo- and striato-cortical networks during initial motor sequence learning (MSL) are critical for memory consolidation. We have recently shown that prefrontal stimulation applied prior to initial MSL can alter these learning-related responses. In the present study, we investigated whether such stimulation-induced modulations of brain responses can influence motor memory consolidation at different timescales. Specifically, we examined the effect of prefrontal stimulation on the behavioral and neural responses associated to (i) fast consolidation processes occurring during short rest episodes interspersed with practice during initial learning (i.e., micro timescale) and (ii) slow consolidation process taking place across practice sessions separated by 24h (i.e., macro timescale). To do so, we applied active (inhibitory or facilitatory) or control theta-burst stimulation to the prefrontal cortex of young healthy participants before they were trained on an MSL task while their brain activity was recorded using functional magnetic resonance imaging (fMRI). Motor performance was retested, in the MRI scanner, after a night of sleep. Both our behavioral and brain imaging results indicate that while stimulation did not modulate consolidation at the macro timescale, it disrupted the micro-offline consolidation process. Specifically, our behavioral data indicate that active - as compared to control - stimulation resulted in a decrease in micro-offline gains in performance over the short rest intervals. At the brain level, stimulation disrupted activity in the caudate nucleus and the hippocampus during the micro-offline intervals. Additionally, multivariate pattern persistence from task into inter-practice rest episodes - which is thought to reflect the reactivation of learning-related patterns - was hindered by active prefrontal stimulation in the hippocampus and caudate nucleus. Importantly, stimulation also altered the link between the brain and the behavioral markers of the micro-offline consolidation process. These results collectively suggest that active prefrontal stimulation prior to MSL disrupted both the behavioral and neural correlates of motor memory consolidation at the micro timescale. Copy rights belong to original authors. Visit the link for more info Podcast created by Paper Player, LLC

In this episode from Bitcoin Amsterdam, we interviewed Attila Toth, Developer Advocate at Timescale, a time-series data analytics scaling solution. Attila tells us about Timescale's high-performance platform built on PostgreSQL that brings web2 scaling solutions into the web3 cloud, allowing users to build layers and scale them faster while staying under budget. Timescale @TimescaleDB Jason on Twitter: @JaysCryptoLife ************************************* BCCN3.com | Blockchain, Cryptocurrency, NFTs and Web3. Subscribe to our newsletter! Twitter: @bccn3_media Instagram: @bccn3_media Discord: https://discord.com/invite/f3wRUrWy6K LinkedIn: https://www.linkedin.com/company/bccn3

Do you remember the episodes where we interviewed researchers from the LLUNE? If you haven't listened to them yet, go back to episodes Ophiolites, Rocks under pressure, and Biostratigraphy with Dr. Luke Milan, Dr. Tim Chapman, and Dr. Maritta Betts from LLUNE. In this Bonus episode, Marissa talks with DrB about the Geological Timescales and […]

In this episode of Scaling Postgres, we discuss using rust for Postgres extensions, performance comparisons of TimescaleDB vs. Postgres, uninterrupted writes when sharding in Citus and the Postgres data flow. Subscribe at https://www.scalingpostgres.com to get notified of new episodes. Links for this episode: https://postgresml.org/blog/postgresml-is-moving-to-rust-for-our-2.0-release/ https://www.timescale.com/blog/postgresql-timescaledb-1000x-faster-queries-90-data-compression-and-much-more/ https://www.citusdata.com/blog/2022/09/19/citus-11-1-shards-postgres-tables-without-interruption/ https://www.crunchydata.com/blog/postgres-data-flow https://www.cybertec-postgresql.com/en/postgresql-sequences-vs-invoice-numbers/ https://postgrespro.com/blog/pgsql/5969741 https://www.crunchydata.com/blog/fun-with-postgres-functions https://www.depesz.com/2022/09/18/what-is-lateral-what-is-it-for-and-how-can-one-use-it/ https://www.postgresql.fastware.com/blog/column-lists-in-logical-replication-publications https://blog.dalibo.com/2022/09/19/psycopg-pipeline-mode.html https://pganalyze.com/blog/5mins-postgres-python-psycopg-3-1-pipeline-mode-query-performance https://ideia.me/using-the-timescale-gem-with-ruby https://b-peng.blogspot.com/2022/09/configuring-vip-route-table.html https://postgres.fm/episodes/index-maintenance https://postgresql.life/post/peter_smith/ https://www.rubberduckdevshow.com/episodes/59-rails-postgres-scaling-with-andrew-atkinson/  

Today we're talking to Mike Freedman, co-founder and CTO of Timescale; and we discuss the impact of time series data; how Mike's experience as a professor gives him insight as a CTO; and how people are getting ahead professionally by leaning into their strengths. All of this right here, right now, on the Modern CTO Podcast! Check out more of Mike and Timescale at https://www.timescale.com/!

This week's guests are Ajay Kulkarni (CEO) and Mike Freedman (CTO), co-founders of Timescale, the startup behind the popular relational database for time-series and analytics. Mike is also a Professor of Computer Science at Princeton University. Our conversation took place a few weeks after Timescale raised a massive funding round and achieved unicorn status. Download the FREE Report: 2022 Data Engineering Survey Report → https://gradientflow.com/2022desurvey/?utm_source=DEpodcastSubscribe: Apple • Android • Spotify • Stitcher • Google • AntennaPod • RSS.Detailed show notes can be found on The Data Exchange web site.

We are thrilled to have Kate Asack, the Chief Operating Officer of TimeScale Financial in today's episode. 'TimeScale Financial' is a financial planning and retirement plan advisory firm dedicated to helping people achieve and enjoy financial independence. Previously known as Coastal Capital Group, in May 2021, the firm announced that it is has rebranded itself under the name TimeScale Financial.Today's powerful episode has everything you need to know about rebranding, business expansion, and fostering a healthy work culture in a hybrid business model. Why is it important to be authentic, accountable, and confident? You'll receive answers that'll resonate with people at different stages of their careers. Find the agenda of our conversation with Kate below: 01:21 About Kate's Role03:05 How Did Kate get to TimeScale Financial? 05:00 The Genesis of the Rebrand07:50 Expansion during the pandemic 10:00 Transitioning into a Hybrid Model19:20 How to create a healthy work culture 22:00 How to come up with brand values 28:17 The importance of education 35:14" I was going to help people reach their financial goals."50:47 "Positioning is everything!".58:56 Kate's take on social media 01:01:35 Success tips for people coming into the industry01:03:00 Best way to get in touch

full recording: https://share.transistor.fm/s/ae30126aTimescale Series C: https://news.ycombinator.com/item?id=30430000Timescale vs Influx: https://news.ycombinator.com/item?id=17766566Timescale vs Clickhouse: https://news.ycombinator.com/item?id=29096541Timescale launch: https://news.ycombinator.com/item?id=14984464

In this episode of Scaling Postgres, we discuss optimizing trigram searches, a review of Postgres replication, improvements to logical replication and a significant Timescale investment. Subscribe at https://www.scalingpostgres.com to get notified of new episodes. Links for this episode: https://alexklibisz.com/2022/02/18/optimizing-postgres-trigram-search.html https://pganalyze.com/blog/5mins-postgres-optimizing-postgres-text-search-trigrams-gist-indexes https://www.enterprisedb.com/blog/replication-revue https://www.percona.com/blog/logical-replication-decoding-improvements-in-postgresql-13-and-14/ https://www.timescale.com/blog/year-of-the-tiger-110-million-to-build-the-future-of-data-for-developers-worldwide/ https://www.shayon.dev/post/2022/47/pg-osc-zero-downtime-schema-changes-in-postgresql/ https://www.cybertec-postgresql.com/en/monitoring-google-cloud-postgresql-with-pgwatch2/ https://postgresql.verite.pro/blog/2022/02/21/psql-hack-select-except.html https://postgresql.life/post/julia_gugel/ https://www.rubberduckdevshow.com/episodes/31-how-to-learn-a-new-code-base/  

In this episode, Ryan and Bhavin interview Vineeth Pothulapati, a product manager at Timescale, and talk about Kubernetes Observability. The discussion dives into what are the three pillars for Observability and how users can leverage different CNCF and Open-source tools like Prometheus, Promscale, and tobs - The Observability Stack for Kubernetes to get started with Observability. Show links: Vineeth Pothulapati: https://twitter.com/VineethReddy02 https://opentelemetry.io/ Promscale - https://github.com/timescale/promscale Kube-Prometheus stack - https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack tobs - https://github.com/timescale/tobs Timescale DB - https://www.youtube.com/watch?v=MFudksxlZjk PX-Backup As A Service - Early Access Program NetApp Astra Enhancements TechTarget storage magazine and search storage announce storage products of the year 2021 award winners

PROMO TIME: Check out the brand new podcast THE KOMMENT for all the updates and insightful takes on the world of sports. Beyond that, we talk about changing up that routine and living on a different timescale. Everybody's favorite learning experience, Random Wiki Article Guessing Game.

Tim is the CEO and Co-Founder of Correlated, the leading product-led revenue platform for sales teams. Correlated recently launched publicly and announced an $8.3 million round of funding led by Harrison Metal and NextView Ventures. Prior to founding Correlated, Tim was an early executive team member at two data and analytics startups: Facet and Timescale. Timescale recently raised a $40 million Series B from Redpoint. Earlier in his career he was on the founding team of TapCommerce, a leading marketing tech startup which was acquired by Twitter for a reported $100 million. Tim has led sales, partnerships and go-to-market teams throughout his career and has witnessed the transition to product-led growth as a go-to-market motion firsthand." He also plays a mean game of Poker.  We talk Product Led Growth/Revenue. What is PLG? Hype and reality….  What are its strengths and limitations? How do product managers work in the PLG model? Which team in the revenue org is most responsible for expansion, sales or CS? How do sales teams in companies with a PLG motion optimally insert themselves into GTM? When should PLG companies hire sales? Are “traditional” SaaS companies starting to pursue a PLG model? What's working/not working?  

4 Things Industry 4.0 Update This Week 1.0 - Litmus Automation awarded a $4m contract with CESMII

Timescale, makers of the open source TimescaleDB time series database, announced a $40 million Series B financing round today. The investment comes just over two years after it got a $15 million Series A. Redpoint Ventures led today's round with help from existing investors Benchmark, New Enterprise Associates, Icon Ventures and Two Sigma Ventures. The […]

Lenovo expands its Linux lineup in a big way, with 30 Ubuntu systems. And why Microsoft Edge on Linux might be more significant than you think. Plus, the latest Mozilla project being spun-out, and how Timescale might have a solution for a self-sustaining open-source business in the cloud era.

It's a big day for Timescale, makers of the open source time series database, TimescaleDB. The company announced a $15 million investment and a new enterprise version of the product. The investment is technically an extension of the $12.4 million Series A it raised last January, which it's referring to as A1. Today's round is led by Icon Ventures with existing investors Benchmark, NEA and Two Sigma Ventures also participating.