Podcasts about SQL

A kid builds a website for Game Boy Advance tips. Then another one. Then a racing game with a contact form he didn't think twice about. Until, someone hit it with a SQL injection. That moment cracked open a door he never planned to walk through. Years later, he's still walking. Past classical computing, past the ones and zeros we all know and into a space where a bit doesn't have to choose. One where particles hold their breath until someone measures them. This is the story of someone who cut their teeth building websites about gaming tips and a comedy sketch audio site that hit number one on G4TV. Now he's volunteering at DEF CON's Quantum Village, building browser-based quantum simulations, and trying to make the most complex frontier in computing feel a little less sci-fi.TIMESTAMPS00:00 Introduction to Robert Covington and His Journey00:51 From Web Projects to Security Awareness03:51 Diving into Quantum Computing06:22 Understanding Quantum Concepts08:31 Making Quantum Accessible with Qubitide.dev11:13 Quantum in Enterprise: Use Cases and Costs13:14 Involvement with Quantum Village and Community Initiatives15:17 Emerging Job Opportunities in Quantum Computing17:27 Learning Resources for Quantum Computing19:31 Understanding Q Day and Its Implications23:16 The Role of Quantum Random Number Generators25:38 Unique Bar Experiences and Quantum ThemesSYMLINKS[Robert Covington – LinkedIn] – https://www.linkedin.com/in/robert-covington-2693a914b[A LinkedIn profile where Robert Covington shares posts about quantum computing, security conferences, and experiments with quantum simulations and QPU workflows.][QubitIDE] - https://qubitide.dev[A quantum computing learning and experimentation platform created by Robert Covington. It aims to make quantum computing more accessible by allowing developers to explore simulations in the browser and eventually integrate quantum processing workflows.][Amazon Braket] - https://aws.amazon.com/braket/[A cloud-based quantum computing service from Amazon Web Services that allows developers and researchers to run quantum algorithms on simulators and real quantum hardware without needing to own physical quantum machines.][PennyLane] - https://pennylane.ai/[An open-source Python library developed by Xanadu for quantum computing and quantum machine learning. It enables users to build and run quantum programs on simulators or real quantum hardware.][Qiskit] - https://qiskit.org/[An open-source quantum computing software development kit created by IBM. It provides tools for building quantum circuits, running simulations, and executing programs on IBM quantum computers.][D-Wave Systems] - https://www.dwavesys.com/[A quantum computing company specializing in quantum annealing hardware and optimization systems. Their machines are used by research institutions and organizations exploring practical quantum applications.][IBM Quantum Learning] - https://quantum.ibm.com/learn[IBM's official learning platform that provides tutorials, documentation, and educational resources for beginners and developers who want to learn quantum computing and use IBM quantum tools.][Quantum Economic Development Consortium (QED-C)] - https://quantumconsortium.org/[An industry consortium focused on strengthening the quantum technology ecosystem through collaboration, workforce development, and industry initiatives.][Barcode Security Podcast] - https://barcodesecurity.com/[The official website of the Barcode podcast hosted by Chris Glanden, featuring discussions on cybersecurity, emerging technologies, and interviews with experts in the field.]

AI Agent Hacks McKinsey Chatbot in 2 Hours, NPM Phantom Raven, Router Malware & Trojaned AI Models This episode covers how researchers at CodeWall used an autonomous AI security agent to gain read/write access to McKinsey's internal chatbot Lilli database in about two hours by chaining exposed APIs and an SQL injection, potentially exposing 46.5 million chats, 728,000 files, 57,000 accounts, and 95 system prompts, with McKinsey saying the issues were fixed and no unauthorized access was found. It also reports on the Phantom Raven supply-chain campaign that published 88 malicious NPM packages using a runtime-downloaded payload to steal developer system data like SSH keys and host details. A study warns that 83% of 800 million compromised passwords still meet complexity rules, highlighting credential-stuffing risk and the need for breach checks and MFA. The show notes 14,000+ routers infected with persistent malware often requiring factory resets plus hardening, and discusses Trojan backdoors embedded in AI models that trigger misbehavior under specific inputs, calling for new AI security testing and validation. Cybersecurity Today  would like to thank Meter for their support in bringing you this podcast. Meter delivers a complete networking stack, wired, wireless and cellular in one integrated solution that's built for performance and scale.  You can find them at Meter.com/cst 00:00 Sponsor Meter Intro 00:20 Headlines And Welcome 00:55 AI Agent Hacks McKinsey Bot 03:44 Phantom Raven NPM Malware 05:55 Strong Passwords Still Leaked 07:55 Router Malware That Persists 09:36 Trojan Backdoors In AI Models 12:01 Call For AI Backdoor Research 12:30 Sponsor Meter Outro 13:13 Sign Off

Nik and Michael are joined by Regina Obe and Paul Ramsey to discuss PostGIS. Here are some links to things they mentioned:Regina Obe https://postgres.fm/people/regina-obePaul Ramsey https://postgres.fm/people/paul-ramseyPostGIS https://postgis.netMobilityDB https://github.com/MobilityDB/MobilityDBpgRouting https://github.com/pgRouting/pgroutingGoogle BigQuery GIS public alpha blog post https://cloud.google.com/blog/products/data-analytics/whats-happening-bigquery-integrated-machine-learning-maps-and-morePostGIS Day 2025 talk recordings https://www.youtube.com/watch?v=wuNO_cW2g-0&list=PLavJpcg8cl1EkQWoCbczsOjFTe-SHg_8mpg_lake https://github.com/Snowflake-Labs/pg_lakeGeoParquet https://geoparquet.orgST_DWithin https://postgis.net/docs/ST_DWithin.htmlPostgres JSONB Columns and TOAST: A Performance Guide https://www.snowflake.com/en/engineering-blog/postgres-jsonb-columns-and-toastFOSS4G https://foss4g.orgOpenStreetMap https://www.openstreetmap.orgPgDay Boston https://2026.pgdayboston.orgSKILL.md file https://github.com/postgis/postgis/blob/68dde711039986b47eb62feda45bb24b13b0ea37/doc/SKILL.mdProduction query plans without production data (blog post by Radim Marek) https://boringsql.com/posts/portable-statsPostgreSQL: Up and Running, 4th Edition (by Regina Obe, Leo Hsu) https://www.oreilly.com/library/view/postgresql-up-and/9798341660885~~~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 credit to:Jessie Draws for the elephant artwork

Turbopuffer came out of a reading app.In 2022, Simon was helping his friends at Readwise scale their infra for a highly requested feature: article recommendations and semantic search. Readwise was paying ~$5k/month for their relational database and vector search would cost ~$20k/month making the feature too expensive to ship. In 2023 after mulling over the problem from Readwise, Simon decided he wanted to “build a search engine” which became Turbopuffer.We discuss:• Simon's path: Denmark → Shopify infra for nearly a decade → “angel engineering” across startups like Readwise, Replicate, and Causal → turbopuffer almost accidentally becoming a company • The Readwise origin story: building an early recommendation engine right after the ChatGPT moment, seeing it work, then realizing it would cost ~$30k/month for a company spending ~$5k/month total on infra and getting obsessed with fixing that cost structure • Why turbopuffer is “a search engine for unstructured data”: Simon's belief that models can learn to reason, but can't compress the world's knowledge into a few terabytes of weights, so they need to connect to systems that hold truth in full fidelity • The three ingredients for building a great database company: a new workload, a new storage architecture, and the ability to eventually support every query plan customers will want on their data • The architecture bet behind turbopuffer: going all in on object storage and NVMe, avoiding a traditional consensus layer, and building around the cloud primitives that only became possible in the last few years • Why Simon hated operating Elasticsearch at Shopify: years of painful on-call experience shaped his obsession with simplicity, performance, and eliminating state spread across multiple systems • The Cursor story: launching turbopuffer as a scrappy side project, getting an email from Cursor the next day, flying out after a 4am call, and helping cut Cursor's costs by 95% while fixing their per-user economics • The Notion story: buying dark fiber, tuning TCP windows, and eating cross-cloud costs because Simon refused to compromise on architecture just to close a deal faster • Why AI changes the build-vs-buy equation: it's less about whether a company can build search infra internally, and more about whether they have time especially if an external team can feel like an extension of their own • Why RAG isn't dead: coding companies still rely heavily on search, and Simon sees hybrid retrieval semantic, text, regex, SQL-style patterns becoming more important, not less • How agentic workloads are changing search: the old pattern was one retrieval call up front; the new pattern is one agent firing many parallel queries at once, turning search into a highly concurrent tool call • Why turbopuffer is reducing query pricing: agentic systems are dramatically increasing query volume, and Simon expects retrieval infra to adapt to huge bursts of concurrent search rather than a small number of carefully chosen calls • The philosophy of “playing with open cards”: Simon's habit of being radically honest with investors, including telling Lachy Groom he'd return the money if turbopuffer didn't hit PMF by year-end • The “P99 engineer”: Simon's framework for building a talent-dense company, rejecting by default unless someone on the team feels strongly enough to fight for the candidate —Simon Hørup Eskildsen• LinkedIn: https://www.linkedin.com/in/sirupsen• X: https://x.com/Sirupsen• https://sirupsen.com/aboutturbopuffer• https://turbopuffer.com/Full Video PodTimestamps00:00:00 The PMF promise to Lachy Groom00:00:25 Intro and Simon's background00:02:19 What turbopuffer actually is00:06:26 Shopify, Elasticsearch, and the pain behind the company00:10:07 The Readwise experiment that sparked turbopuffer00:12:00 The insight Simon couldn't stop thinking about00:17:00 S3 consistency, NVMe, and the architecture bet00:20:12 The Notion story: latency, dark fiber, and conviction00:25:03 Build vs. buy in the age of AI00:26:00 The Cursor story: early launch to breakout customer00:29:00 Why code search still matters00:32:00 Search in the age of agents00:34:22 Pricing turbopuffer in the AI era00:38:17 Why Simon chose Lachy Groom00:41:28 Becoming a founder on purpose00:44:00 The “P99 engineer” philosophy00:49:30 Bending software to your will00:51:13 The future of turbopuffer00:57:05 Simon's tea obsession00:59:03 Tea kits, X Live, and P99 LiveTranscriptSimon Hørup Eskildsen: I don't think I've said this publicly before, but I just called Lockey and was like, local Lockie. Like if this doesn't have PMF by the end of the year, like we'll just like return all the money to you. But it's just like, I don't really, we, Justine and I don't wanna work on this unless it's really working.So we want to give it the best shot this year and like we're really gonna go for it. We're gonna hire a bunch of people. We're just gonna be honest with everyone. Like when I don't know how to play a game, I just play with open cards. Lockey was the only person that didn't, that didn't freak out. He was like, I've never heard anyone say that before.Alessio: Hey everyone, welcome to the Leading Space podcast. This is Celesio Pando, Colonel Laz, and I'm joined by Swix, editor of Leading Space.swyx: Hello. Hello, uh, we're still, uh, recording in the Ker studio for the first time. Very excited. And today we are joined by Simon Eski. Of Turbo Farer welcome.Simon Hørup Eskildsen: Thank you so much for having me.swyx: Turbo Farer has like really gone on a huge tear, and I, I do have to mention that like you're one of, you're not my newest member of the Danish AHU Mafia, where like there's a lot of legendary programmers that have come out of it, like, uh, beyond Trotro, Rasmus, lado Berg and the V eight team and, and Google Maps team.Uh, you're mostly a Canadian now, but isn't that interesting? There's so many, so much like strong Danish presence.Simon Hørup Eskildsen: Yeah, I was writing a post, um, not that long ago about sort of the influences. So I grew up in Denmark, right? I left, I left when, when I was 18 to go to Canada to, to work at Shopify. Um, and so I, like, I've, I would still say that I feel more Danish than, than Canadian.This is also the weird accent. I can't say th because it, this is like, I don't, you know, my wife is also Canadian, um, and I think. I think like one of the things in, in Denmark is just like, there's just such a ruthless pragmatism and there's also a big focus on just aesthetics. Like, they're like very, people really care about like where, what things look like.Um, and like Canada has a lot of attributes, US has, has a lot of attributes, but I think there's been lots of the great things to carry. I don't know what's in the water in Ahu though. Um, and I don't know that I could be considered part of the Mafi mafia quite yet, uh, compared to the phenomenal individuals we just mentioned.Barra OV is also, uh, Danish Canadian. Okay. Yeah. I don't know where he lives now, but, and he's the PHP.swyx: Yeah. And obviously Toby German, but moved to Canada as well. Yes. Like this is like import that, uh, that, that is an interesting, um, talent move.Alessio: I think. I would love to get from you. Definition of Turbo puffer, because I think you could be a Vector db, which is maybe a bad word now in some circles, you could be a search engine.It's like, let, let's just start there and then we'll maybe run through the history of how you got to this point.Simon Hørup Eskildsen: For sure. Yeah. So Turbo Puffer is at this point in time, a search engine, right? We do full text search and we do vector search, and that's really what we're specialized in. If you're trying to do much more than that, like then this might not be the right place yet, but Turbo Buffer is all about search.The other way that I think about it is that we can take all of the world's knowledge, all of the exabytes and exabytes of data that there is, and we can use those tokens to train a model, but we can't compress all of that into a few terabytes of weights, right? Compress into a few terabytes of weights, how to reason with the world, how to make sense of the knowledge.But we have to somehow connect it to something externally that actually holds that like in full fidelity and truth. Um, and that's the thing that we intend to become. Right? That's like a very holier than now kind of phrasing, right? But being the search engine for unstructured, unstructured data is the focus of turbo puffer at this point in time.Alessio: And let's break down. So people might say, well, didn't Elasticsearch already do this? And then some other people might say, is this search on my data, is this like closer to rag than to like a xr, like a public search thing? Like how, how do you segment like the different types of search?Simon Hørup Eskildsen: The way that I generally think about this is like, there's a lot of database companies and I think if you wanna build a really big database company, sort of, you need a couple of ingredients to be in the air.We don't, which only happens roughly every 15 years. You need a new workload. You basically need the ambition that every single company on earth is gonna have data in your database. Multiple times you look at a company like Oracle, right? You will, like, I don't think you can find a company on earth with a digital presence that it not, doesn't somehow have some data in an Oracle database.Right? And I think at this point, that's also true for Snowflake and Databricks, right? 15 years later it's, or even more than that, there's not a company on earth that doesn't, in. Or directly is consuming Snowflake or, or Databricks or any of the big analytics databases. Um, and I think we're in that kind of moment now, right?I don't think you're gonna find a company over the next few years that doesn't directly or indirectly, um, have all their data available for, for search and connect it to ai. So you need that new workload, like you need something to be happening where there's a new workload that causes that to happen, and that new workload is connecting very large amounts of data to ai.The second thing you need. The second condition to build a big database company is that you need some new underlying change in the storage architecture that is not possible from the databases that have come before you. If you look at Snowflake and Databricks, right, commoditized, like massive fleet of HDDs, like that was not possible in it.It just wasn't in the air in the nineties, right? So you just didn't, we just didn't build these systems. S3 and and and so on was not around. And I think the architecture that is now possible that wasn't possible 15 years ago is to go all in on NVME SSDs. It requires a particular type of architecture for the database that.It's difficult to retrofit onto the databases that are already there, including the ones you just mentioned. The second thing is to go all in on OIC storage, more so than we could have done 15 years ago. Like we don't have a consensus layer, we don't really have anything. In fact, you could turn off all the servers that Turbo Buffer has, and we would not lose any data because we have all completely all in on OIC storage.And this means that our architecture is just so simple. So that's the second condition, right? First being a new workload. That means that every company on earth, either indirectly or directly, is using your database. Second being, there's some new storage architecture. That means that the, the companies that have come before you can do what you're doing.I think the third thing you need to do to build a big database company is that over time you have to implement more or less every Cory plan on the data. What that means is that you. You can't just get stuck in, like, this is the one thing that a database does. It has to be ever evolving because when someone has data in the database, they over time expect to be able to ask it more or less every question.So you have to do that to get the storage architecture to the limit of what, what it's capable of. Those are the three conditions.swyx: I just wanted to get a little bit of like the motivation, right? Like, so you left Shopify, you're like principal, engineer, infra guy. Um, you also head of kernel labs, uh, inside of Shopify, right?And then you consulted for read wise and that it kind of gave you that, that idea. I just wanted you to tell that story. Um, maybe I, you've told it before, but, uh, just introduce the, the. People to like the, the new workload, the sort of aha moment for turbo PufferSimon Hørup Eskildsen: For sure. So yeah, I spent almost a decade at Shopify.I was on the infrastructure team, um, from the fairly, fairly early days around 2013. Um, at the time it felt like it was growing so quickly and everything, all the metrics were, you know, doubling year on year compared to the, what companies are contending with today. It's very cute in growth. I feel like lot some companies are seeing that month over month.Um, of course. Shopify compound has been compounding for a very long time now, but I spent a decade doing that and the majority of that was just make sure the site is up today and make sure it's up a year from now. And a lot of that was really just the, um, you know, uh, the Kardashians would drive very, very large amounts of, of data to, to uh, to Shopify as they were rotating through all the merch and building out their businesses.And we just needed to make sure we could handle that. Right. And sometimes these were events, a million requests per second. And so, you know, we, we had our own data centers back in the day and we were moving to the cloud and there was so much sharding work and all of that that we were doing. So I spent a decade just scaling databases ‘cause that's fundamentally what's the most difficult thing to scale about these sites.The database that was the most difficult for me to scale during that time, and that was the most aggravating to be on call for, was elastic search. It was very, very difficult to deal with. And I saw a lot of projects that were just being held back in their ambition by using it.swyx: And I mean, self-hosted.Self-hosted. ‘causeSimon Hørup Eskildsen: it's, yeah, and it commercial, this is like 2015, right? So it's like a very particular vintage. Right. It's probably better at a lot of these things now. Um, it was difficult to contend with and I'm just like, I just think about it. It's an inverted index. It should be good at these kinds of queries and do all of this.And it was, we, we often couldn't get it to do exactly what we needed to do or basically get lucine to do, like expose lucine raw to, to, to what we needed to do. Um, so that was like. Just something that we did on the side and just panic scaled when we needed to, but not a particular focus of mine. So I left, and when I left, I, um, wasn't sure exactly what I wanted to do.I mean, it spent like a decade inside of the same company. I'd like grown up there. I started working there when I was 18.swyx: You only do Rails?Simon Hørup Eskildsen: Yeah. I mean, yeah. Rails. And he's a Rails guy. Uh, love Rails. So good. Um,Alessio: we all wish we could still work in Rails.swyx: I know know. I know, but some, I tried learning Ruby.It's just too much, like too many options to do the same thing. It's, that's my, I I know there's a, there's a way to do it.Simon Hørup Eskildsen: I love it. I don't know that I would use it now, like given cloud code and, and, and cursor and everything, but, um, um, but still it, like if I'm just sitting down and writing a teal code, that's how I think.But anyway, I left and I wasn't, I talked to a couple companies and I was like, I don't. I need to see a little bit more of the world here to know what I'm gonna like focus on next. Um, and so what I decided is like I was gonna, I called it like angel engineering, where I just hopped around in my friend's companies in three months increments and just helped them out with something.Right. And, and just vested a bit of equity and solved some interesting infrastructure problem. So I worked with a bunch of companies at the time, um, read Wise was one of them. Replicate was one of them. Um, causal, I dunno if you've tried this, it's like a, it's a spreadsheet engine Yeah. Where you can do distribution.They sold recently. Yeah. Um, we've been, we used that in fp and a at, um, at Turbo Puffer. Um, so a bunch of companies like this and it was super fun. And so we're the Chachi bt moment happened, I was with. With read Wise for a stint, we were preparing for the reader launch, right? Which is where you, you cue articles and read them later.And I was just getting their Postgres up to snuff, like, which basically boils down to tuning, auto vacuum. So I was doing that and then this happened and we were like, oh, maybe we should build a little recommendation engine and some features to try to hook in the lms. They were not that good yet, but it was clear there was something there.And so I built a small recommendation engine just, okay, let's take the articles that you've recently read, right? Like embed all the articles and then do recommendations. It was good enough that when I ran it on one of the co-founders of Rey's, like I found out that I got articles about, about having a child.I'm like, oh my God, I didn't, I, I didn't know that, that they were having a child. I wasn't sure what to do with that information, but the recommendation engine was good enough that it was suggesting articles, um, about that. And so there was, there was recommendations and uh, it actually worked really well.But this was a company that was spending maybe five grand a month in total on all their infrastructure and. When I did the napkin math on running the embeddings of all the articles, putting them into a vector index, putting it in prod, it's gonna be like 30 grand a month. That just wasn't tenable. Right?Like Read Wise is a proudly bootstrapped company and it's paying 30 grand for infrastructure for one feature versus five. It just wasn't tenable. So sort of in the bucket of this is useful, it's pretty good, but let us, let's return to it when the costs come down.swyx: Did you say it grows by feature? So for five to 30 is by the number of, like, what's the, what's the Scaling factor scale?It scales by the number of articles that you embed.Simon Hørup Eskildsen: It does, but what I meant by that is like five grand for like all of the other, like the Heroku, dinos, Postgres, like all the other, and this then storage is 30. Yeah. And then like 30 grand for one feature. Right. Which is like, what other articles are related to this one.Um, so it was just too much right to, to power everything. Their budget would've been maybe a few thousand dollars, which still would've been a lot. And so we put it in a bucket of, okay, we're gonna do that later. We'll wait, we will wait for the cost to come down. And that haunted me. I couldn't stop thinking about it.I was like, okay, there's clearly some latent demand here. If the cost had been a 10th, we would've shipped it and. This was really the only data point that I had. Right. I didn't, I, I didn't, I didn't go out and talk to anyone else. It was just so I started reading Right. I couldn't, I couldn't help myself.Like I didn't know what like a vector index is. I, I generally barely do about how to generate the vectors. There was a lot of hype about, this is a early 2023. There was a lot of hype about vector databases. There were raising a lot of money and it's like, I really didn't know anything about it. It's like, you know, trying these little models, fine tuning them.Like I was just trying to get sort of a lay of the land. So I just sat down. I have this. A GitHub repository called Napkin Math. And on napkin math, there's just, um, rows of like, oh, this is how much bandwidth. Like this is how many, you know, you can do 25 gigabytes per second on average to dram. You can do, you know, five gigabytes per second of rights to an SSD, blah blah.All of these numbers, right? And S3, how many you could do per, how much bandwidth can you drive per connection? I was just sitting down, I was like, why hasn't anyone build a database where you just put everything on O storage and then you puff it into NVME when you use the data and you puff it into dram if you're, if you're querying it alive, it's just like, this seems fairly obvious and you, the only real downside to that is that if you go all in on o storage, every right will take a couple hundred milliseconds of latency, but from there it's really all upside, right?You do the first go, it takes half a second. And it sort of occurred to me as like, well. The architecture is really good for that. It's really good for AB storage, it's really good for nvm ESSD. It's, well, you just couldn't have done that 10 years ago. Back to what we were talking about before. You really have to build a database where you have as few round trips as possible, right?This is how CPUs work today. It's how NVM E SSDs work. It's how as, um, as three works that you want to have a very large amount of outstanding requests, right? Like basically go to S3, do like that thousand requests to ask for data in one round trip. Wait for that. Get that, like, make a new decision. Do it again, and try to do that maybe a maximum of three times.But no databases were designed that way within NVME as is ds. You can drive like within, you know, within a very low multiple of DRAM bandwidth if you use it that way. And same with S3, right? You can fully max out the network card, which generally is not maxed out. You get very, like, very, very good bandwidth.And, but no one had built a database like that. So I was like, okay, well can't you just, you know, take all the vectors right? And plot them in the proverbial coordinate system. Get the clusters, put a file on S3 called clusters, do json, and then put another file for every cluster, you know, cluster one, do js O cluster two, do js ON you know that like it's two round trips, right?So you get the clusters, you find the closest clusters, and then you download the cluster files like the, the closest end. And you could do this in two round trips.swyx: You were nearest neighbors locally.Simon Hørup Eskildsen: Yes. Yes. And then, and you would build this, this file, right? It's just like ultra simplistic, but it's not a far shot from what the first version of Turbo Buffer was.Why hasn't anyone done thatAlessio: in that moment? From a workload perspective, you're thinking this is gonna be like a read heavy thing because they're doing recommend. Like is the fact that like writes are so expensive now? Oh, with ai you're actually not writing that much.Simon Hørup Eskildsen: At that point I hadn't really thought too much about, well no actually it was always clear to me that there was gonna be a lot of rights because at Shopify, the search clusters were doing, you know, I don't know, tens or hundreds of crew QPS, right?‘cause you just have to have a human sit and type in. But we did, you know, I don't know how many updates there were per second. I'm sure it was in the millions, right into the cluster. So I always knew there was like a 10 to 100 ratio on the read write. In the read wise use case. It's, um, even, even in the read wise use case, there'd probably be a lot fewer reads than writes, right?There's just a lot of churn on the amount of stuff that was going through versus the amount of queries. Um, I wasn't thinking too much about that. I was mostly just thinking about what's the fundamentally cheapest way to build a database in the cloud today using the primitives that you have available.And this is it, right? You just, now you have one machine and you know, let's say you have a terabyte of data in S3, you paid the $200 a month for that, and then maybe five to 10% of that data and needs to be an NV ME SSDs and less than that in dram. Well. You're paying very, very little to inflate the data.swyx: By the way, when you say no one else has done that, uh, would you consider Neon, uh, to be on a similar path in terms of being sort of S3 first and, uh, separating the compute and storage?Simon Hørup Eskildsen: Yeah, I think what I meant with that is, uh, just build a completely new database. I don't know if we were the first, like it was very much, it was, I mean, I, I hadn't, I just looked at the napkin math and was like, this seems really obvious.So I'm sure like a hundred people came up with it at the same time. Like the light bulb and every invention ever. Right. It was just in the air. I think Neon Neon was, was first to it. And they're trying, they're retrofitted onto Postgres, right? And then they built this whole architecture where you have, you have it in memory and then you sort of.You know, m map back to S3. And I think that was very novel at the time to do it for, for all LTP, but I hadn't seen a database that was truly all in, right. Not retrofitting it. The database felt built purely for this no consensus layer. Even using compare and swap on optic storage to do consensus. I hadn't seen anyone go that all in.And I, I mean, there, there, I'm sure there was someone that did that before us. I don't know. I was just looking at the napkin mathswyx: and, and when you say consensus layer, uh, are you strongly relying on S3 Strong consistency? You are. Okay.SoSimon Hørup Eskildsen: that is your consensus layer. It, it is the consistency layer. And I think also, like, this is something that most people don't realize, but S3 only became consistent in December of 2020.swyx: I remember this coming out during COVID and like people were like, oh, like, it was like, uh, it was just like a free upgrade.Simon Hørup Eskildsen: Yeah.swyx: They were just, they just announced it. We saw consistency guys and like, okay, cool.Simon Hørup Eskildsen: And I'm sure that they just, they probably had it in prod for a while and they're just like, it's done right.And people were like, okay, cool. But. That's a big moment, right? Like nv, ME SSDs, were also not in the cloud until around 2017, right? So you just sort of had like 2017 nv, ME SSDs, and people were like, okay, cool. There's like one skew that does this, whatever, right? Takes a few years. And then the second thing is like S3 becomes consistent in 2020.So now it means you don't have to have this like big foundation DB or like zookeeper or whatever sitting there contending with the keys, which is how. You know, that's what Snowflake and others have do so muchswyx: for goneSimon Hørup Eskildsen: Exactly. Just gone. Right? And so just push to the, you know, whatever, how many hundreds of people they have working on S3 solved and then compare and swap was not in S3 at this point in time,swyx: by the way.Uh, I don't know what that is, so maybe you wanna explain. Yes. Yeah.Simon Hørup Eskildsen: Yes. So, um, what Compare and swap is, is basically, you can imagine that if you have a database, it might be really nice to have a file called metadata json. And metadata JSON could say things like, Hey, these keys are here and this file means that, and there's lots of metadata that you have to operate in the database, right?But that's the simplest way to do it. So now you have might, you might have a lot of servers that wanna change the metadata. They might have written a file and want the metadata to contain that file. But you have a hundred nodes that are trying to contend with this metadata that JSON well, what compare and Swap allows you to do is basically just you download the file, you make the modifications, and then you write it only if it hasn't changed.While you did the modification and if not you retry. Right? Should just have this retry loops. Now you can imagine if you have a hundred nodes doing that, it's gonna be really slow, but it will converge over time. That primitive was not available in S3. It wasn't available in S3 until late 2024, but it was available in GCP.The real story of this is certainly not that I sat down and like bake brained it. I was like, okay, we're gonna start on GCS S3 is gonna get it later. Like it was really not that we started, we got really lucky, like we started on GCP and we started on GCP because tur um, Shopify ran on GCP. And so that was the platform I was most available with.Right. Um, and I knew the Canadian team there ‘cause I'd worked with them at Shopify and so it was natural for us to start there. And so when we started building the database, we're like, oh yeah, we have to build a, we really thought we had to build a consensus layer, like have a zookeeper or something to do this.But then we discovered the compare and swap. It's like, oh, we can kick the can. Like we'll just do metadata r json and just, it's fine. It's probably fine. Um, and we just kept kicking the can until we had very, very strong conviction in the idea. Um, and then we kind of just hinged the company on the fact that S3 probably was gonna get this, it started getting really painful in like mid 2024.‘cause we were closing deals with, um, um, notion actually that was running in AWS and we're like, trust us. You, you really want us to run this in GCP? And they're like, no, I don't know about that. Like, we're running everything in AWS and the latency across the cloud were so big and we had so much conviction that we bought like, you know, dark fiber between the AWS regions in, in Oregon, like in the InterExchange and GCP is like, we've never seen a startup like do like, what's going on here?And we're just like, no, we don't wanna do this. We were tuning like TCP windows, like everything to get the latency down ‘cause we had so high conviction in not doing like a, a metadata layer on S3. So those were the three conditions, right? Compare and swap. To do metadata, which wasn't in S3 until late 2024 S3 being consistent, which didn't happen until December, 2020.Uh, 2020. And then NVMe ssd, which didn't end in the cloud until 2017.swyx: I mean, in some ways, like a very big like cloud success story that like you were able to like, uh, put this all together, but also doing things like doing, uh, bind our favor. That that actually is something I've never heard.Simon Hørup Eskildsen: I mean, it's very common when you're a big company, right?You're like connecting your own like data center or whatever. But it's like, it was uniquely just a pain with notion because the, um, the org, like most of the, like if you're buying in Ashburn, Virginia, right? Like US East, the Google, like the GCP and, and AWS data centers are like within a millisecond on, on each other, on the public exchanges.But in Oregon uniquely, the GCP data center sits like a couple hundred kilometers, like east of Portland and the AWS region sits in Portland, but the network exchange they go through is through Seattle. So it's like a full, like 14 milliseconds or something like that. And so anyway, yeah. It's, it's, so we were like, okay, we can't, we have to go through an exchange in Portland.Yeah. Andswyx: you'd rather do this than like run your zookeeper and likeSimon Hørup Eskildsen: Yes. Way rather. It doesn't have state, I don't want state and two systems. Um, and I think all that is just informed by Justine, my co-founder and I had just been on call for so long. And the worst outages are the ones where you have state in multiple places that's not syncing up.So it really came from, from a a, like just a, a very pure source of pain, of just imagining what we would be Okay. Being woken up at 3:00 AM about and having something in zookeeper was not one of them.swyx: You, you're talking to like a notion or something. Do they care or do they just, theySimon Hørup Eskildsen: just, they care about latency.swyx: They latency cost. That's it.Simon Hørup Eskildsen: They just cared about latency. Right. And we just absorbed the cost. We're just like, we have high conviction in this. At some point we can move them to AWS. Right. And so we just, we, we'll buy the fiber, it doesn't matter. Right. Um, and it's like $5,000. Usually when you buy fiber, you buy like multiple lines.And we're like, we can only afford one, but we will just test it that when it goes over the public internet, it's like super smooth. And so we did a lot of, anyway, it's, yeah, it was, that's cool.Alessio: You can imagine talking to the GCP rep and it's like, no, we're gonna buy, because we know we're gonna turn, we're gonna turn from you guys and go to AWS in like six months.But in the meantime we'll do this. It'sSimon Hørup Eskildsen: a, I mean, like they, you know, this workload still runs on GCP for what it's worth. Right? ‘cause it's so, it was just, it was so reliable. So it was never about moving off GCP, it was just about honesty. It was just about giving notion the latency that they deserved.Right. Um, and we didn't want ‘em to have to care about any of this. We also, they were like, oh, egress is gonna be bad. It was like, okay, screw it. Like we're just gonna like vvc, VPC peer with you and AWS we'll eat the cost. Yeah. Whatever needs to be done.Alessio: And what were the actual workloads? Because I think when you think about ai, it's like 14 milliseconds.It's like really doesn't really matter in the scheme of like a model generation.Simon Hørup Eskildsen: Yeah. We were told the latency, right. That we had to beat. Oh, right. So, so we're just looking at the traces. Right. And then sort of like hand draw, like, you know, kind of like looking at the trace and then thinking what are the other extensions of the trace?Right. And there's a lot more to it because it's also when you have, if you have 14 versus seven milliseconds, right. You can fit in another round trip. So we had to tune TCP to try to send as much data in every round trip, prewarm all the connections. And there was, there's a lot of things that compound from having these kinds of round trips, but in the grand scheme it was just like, well, we have to beat the latency of whatever we're up against.swyx: Which is like they, I mean, notion is a database company. They could have done this themselves. They, they do lots of database engineering themselves. How do you even get in the door? Like Yeah, just like talk through that kind of.Simon Hørup Eskildsen: Last time I was in San Francisco, I was talking to one of the engineers actually, who, who was one of our champions, um, at, AT Notion.And they were, they were just trying to make sure that the, you know, per user cost matched the economics that they needed. You know, Uhhuh like, it's like the way I think about, it's like I have to earn a return on whatever the clouds charge me and then my customers have to earn a return on that. And it's like very simple, right?And so there has to be gross margin all the way up and that's how you build the product. And so then our customers have to make the right set of trade off the turbo Puffer makes, and if they're happy with that, that's great.swyx: Do you feel like you're competing with build internally versus buy or buy versus buy?Simon Hørup Eskildsen: Yeah, so, sorry, this was all to build up to your question. So one of the notion engineers told me that they'd sat and probably on a napkin, like drawn out like, why hasn't anyone built this? And then they saw terrible. It was like, well, it literally that. So, and I think AI has also changed the buy versus build equation in terms of, it's not really about can we build it, it's about do we have time to build it?I think they like, I think they felt like, okay, if this is a team that can do that and they, they feel enough like an extension of our team, well then we can go a lot faster, which would be very, very good for them. And I mean, they put us through the, through the test, right? Like we had some very, very long nights to to, to do that POC.And they were really our biggest, our second big customer off the cursor, which also was a lot of late nights. Right.swyx: Yeah. That, I mean, should we go into that story? The, the, the sort of Chris's story, like a lot, um, they credit you a lot for. Working very closely with them. So I just wanna hear, I've heard this, uh, story from Sole's point of view, but like, I'm curious what, what it looks like from your side.Simon Hørup Eskildsen: I actually haven't heard it from Sole's point of view, so maybe you can now cross reference it. The way that I remember it was that, um, the day after we launched, which was just, you know, I'd worked the whole summer on, on the first version. Justine wasn't part of it yet. ‘cause I just, I didn't tell anyone that summer that I was working on this.I was just locked in on building it because it's very easy otherwise to confuse talking about something to actually doing it. And so I was just like, I'm not gonna do that. I'm just gonna do the thing. I launched it and at this point turbo puffer is like a rust binary running on a single eight core machine in a T Marks instance.And me deploying it was like looking at the request log and then like command seeing it or like control seeing it to just like, okay, there's no request. Let's upgrade the binary. Like it was like literally the, the, the, the scrappiest thing. You could imagine it was on purpose because just like at Shopify, we did that all the time.Like, we like move, like we ran things in tux all the time to begin with. Before something had like, at least the inkling of PMF, it was like, okay, is anyone gonna hear about this? Um, and one of the cursor co-founders Arvid reached out and he just, you know, the, the cursor team are like all I-O-I-I-M-O like, um, contenders, right?So they just speak in bullet points and, and facts. It was like this amazing email exchange just of, this is how many QPS we have, this is what we're paying, this is where we're going, blah, blah, blah. And so we're just conversing in bullet points. And I tried to get a call with them a few times, but they were, so, they were like really writing the PMF bowl here, just like late 2023.And one time Swally emails me at like five. What was it like 4:00 AM Pacific time saying like, Hey, are you open for a call now? And I'm on the East coast and I, it was like 7:00 AM I was like, yeah, great, sure, whatever. Um, and we just started talking and something. Then I didn't know anything about sales.It was something that just comp compelled me. I have to go see this team. Like, there's something here. So I, I went to San Francisco and I went to their office and the way that I remember it is that Postgres was down when I showed up at the office. Did SW tell you this? No. Okay. So Postgres was down and so it's like they were distracting with that.And I was trying my best to see if I could, if I could help in any way. Like I knew a little bit about databases back to tuning, auto vacuum. It was like, I think you have to tune out a vacuum. Um, and so we, we talked about that and then, um, that evening just talked about like what would it look like, what would it look like to work with us?And I just said. Look like we're all in, like we will just do what we'll do whatever, whatever you tell us, right? They migrated everything over the next like week or two, and we reduced their cost by 95%, which I think like kind of fixed their per user economics. Um, and it solved a lot of other things. And we were just, Justine, this is also when I asked Justine to come on as my co-founder, she was the best engineer, um, that I ever worked with at Shopify.She lived two blocks away and we were just, okay, we're just gonna get this done. Um, and we did, and so we helped them migrate and we just worked like hell over the next like month or two to make sure that we were never an issue. And that was, that was the cursor story. Yeah.swyx: And, and is code a different workload than normal text?I, I don't know. Is is it just text? Is it the same thing?Simon Hørup Eskildsen: Yeah, so cursor's workload is basically, they, um, they will embed the entire code base, right? So they, they will like chunk it up in whatever they would, they do. They have their own embedding model, um, which they've been public about. Um, and they find that on, on, on their evals.It. There's one of their evals where it's like a 25% improvement on a very particular workload. They have a bunch of blog posts about it. Um, I think it works best on larger code basis, but they've trained their own embedding model to do this. Um, and so you'll see it if you use the cursor agent, it will do searches.And they've also been public around, um, how they've, I think they post trained their model to be very good at semantic search as well. Um, and that's, that's how they use it. And so it's very good at, like, can you find me on the code that's similar to this, or code that does this? And just in, in this queries, they also use GR to supplement it.swyx: Yeah.Simon Hørup Eskildsen: Um, of courseswyx: it's been a big topic of discussion like, is rag dead because gr you know,Simon Hørup Eskildsen: and I mean like, I just, we, we see lots of demand from the coding company to ethicsswyx: search in every part. Yes.Simon Hørup Eskildsen: Uh, we, we, we see demand. And so, I mean, I'm. I like case studies. I don't like, like just doing like thought pieces on this is where it's going.And like trying to be all macroeconomic about ai, that's has turned out to be a giant waste of time because no one can really predict any of this. So I just collect case studies and I mean, cursor has done a great job talking about what they're doing and I hope some of the other coding labs that use Turbo Puffer will do the same.Um, but it does seem to make a difference for particular queries. Um, I mean we can also do text, we can also do RegX, but I should also say that cursors like security posture into Tur Puffer is exceptional, right? They have their own embedding model, which makes it very difficult to reverse engineer. They obfuscate the file paths.They like you. It's very difficult to learn anything about a code base by looking at it. And the other thing they do too is that for their customers, they encrypt it with their encryption keys in turbo puffer's bucket. Um, so it's, it's, it's really, really well designed.swyx: And so this is like extra stuff they did to work with you because you are not part of Cursor.Exactly like, and this is just best practice when working in any database, not just you guys. Okay. Yeah, that makes sense. Yeah. I think for me, like the, the, the learning is kind of like you, like all workloads are hybrid. Like, you know, uh, like you, you want the semantic, you want the text, you want the RegX, you want sql.I dunno. Um, but like, it's silly to like be all in on like one particularly query pattern.Simon Hørup Eskildsen: I think, like I really like the way that, um, um, that swally at cursor talks about it, which is, um, I'm gonna butcher it here. Um, and you know, I'm a, I'm a database scalability person. I'm not a, I, I dunno anything about training models other than, um, what the internet tells me and what.The way he describes is that this is just like cash compute, right? It's like you have a point in time where you're looking at some particular context and focused on some chunk and you say, this is the layer of the neural net at this point in time. That seems fundamentally really useful to do cash compute like that.And, um, how the value of that will change over time. I'm, I'm not sure, but there seems to be a lot of value in that.Alessio: Maybe talk a bit about the evolution of the workload, because even like search, like maybe two years ago it was like one search at the start of like an LLM query to build the context. Now you have a gentech search, however you wanna call it, where like the model is both writing and changing the code and it's searching it again later.Yeah. What are maybe some of the new types of workloads or like changes you've had to make to your architecture for it?Simon Hørup Eskildsen: I think you're right. When I think of rag, I think of, Hey, there's an 8,000 token, uh, context window and you better make it count. Um, and search was a way to do that now. Everything is moving towards the, just let the agent do its thing.Right? And so back to the thing before, right? The LLM is very good at reasoning with the data, and so we're just the tool call, right? And that's increasingly what we see our customers doing. Um, what we're seeing more demand from, from our customers now is to do a lot of concurrency, right? Like Notion does a ridiculous amount of queries in every round trip just because they can't.And I'm also now, when I use the cursor agent, I also see them doing more concurrency than I've ever seen before. So a bit similar to how we designed a database to drive as much concurrency in every round trip as possible. That's also what the agents are doing. So that's new. It means just an enormous amount of queries all at once to the dataset while it's warm in as few turns as possible.swyx: Can I clarify one thing on that?Simon Hørup Eskildsen: Yes.swyx: Is it, are they batching multiple users or one user is driving multiple,Simon Hørup Eskildsen: one user driving multiple, one agent driving.swyx: It's parallel searching a bunch of things.Simon Hørup Eskildsen: Exactly.swyx: Yeah. Yeah, exactly. So yeah, the clinician also did, did this for the fast context thing, like eight parallel at once.Simon Hørup Eskildsen: Yes.swyx: And, and like an interesting problem is, well, how do you make sure you have enough diversity so you're not making the the same request eight times?Simon Hørup Eskildsen: And I think like that's probably also where the hybrid comes in, where. That's another way to diversify. It's a completely different way to, to do the search.That's a big change, right? So before it was really just like one call and then, you know, the LLM took however many seconds to return, but now we just see an enormous amount of queries. So the, um, we just see more queries. So we've like tried to reduce query, we've reduced query pricing. Um, this is probably the first time actually I'm saying that, but the query pricing is being reduced, like five x.Um, and we'll probably try to reduce it even more to accommodate some of these workloads of just doing very large amounts of queries. Um, that's one thing that's changed. I think the right, the right ratio is still very high, right? Like there's still a, an enormous amount of rights per read, but we're starting probably to see that change if people really lean into this pattern.Alessio: Can we talk a little bit about the pricing? I'm curious, uh, because traditionally a database would charge on storage, but now you have the token generation that is so expensive, where like the actual. Value of like a good search query is like much higher because they're like saving inference time down the line.How do you structure that as like, what are people receptive to on the other side too?Simon Hørup Eskildsen: Yeah. I, the, the turbo puffer pricing in the beginning was just very simple. The pricing on these on for search engines before Turbo Puffer was very server full, right? It was like, here's the vm, here's the per hour cost, right?Great. And I just sat down with like a piece of paper and said like, if Turbo Puffer was like really good, this is probably what it would cost with a little bit of margin. And that was the first pricing of Turbo Puffer. And I just like sat down and I was like, okay, like this is like probably the storage amp, but whenever on a piece of paper I, it was vibe pricing.It was very vibe price, and I got it wrong. Oh. Um, well I didn't get it wrong, but like Turbo Puffer wasn't at the first principle pricing, right? So when Cursor came on Turbo Puffer, it was like. Like, I didn't know any VCs. I didn't know, like I was just like, I don't know, I didn't know anything about raising money or anything like that.I just saw that my GCP bill was, was high, was a lot higher than the cursor bill. So Justine and I was just like, well, we have to optimize it. Um, and I mean, to the chagrin now of, of it, of, of the VCs, it now means that we're profitable because we've had so much pricing pressure in the beginning. Because it was running on my credit card and Justine and I had spent like, like tens of thousands of dollars on like compute bills and like spinning off the company and like very like, like bad Canadian lawyers and like things like to like get all of this done because we just like, we didn't know.Right. If you're like steeped in San Francisco, you're just like, you just know. Okay. Like you go out, raise a pre-seed round. I, I never heard a word pre-seed at this point in time.swyx: When you had Cursor, you had Notion you, you had no funding.Simon Hørup Eskildsen: Um, with Cursor we had no funding. Yeah. Um, by the time we had Notion Locke was, Locke was here.Yeah. So it was really just, we vibe priced it 100% from first Principles, but it wasn't, it, it was not performing at first principles, so we just did everything we could to optimize it in the beginning for that, so that at least we could have like a 5% margin or something. So I wasn't freaking out because Cursor's bill was also going like this as they were growing.And so my liability and my credit limit was like actively like calling my bank. It was like, I need a bigger credit. Like it was, yeah. Anyway, that was the beginning. Yeah. But the pricing was, yeah, like storage rights and query. Right. And the, the pricing we have today is basically just that pricing with duct tape and spit to try to approach like, you know, like a, as a margin on the physical underlying hardware.And we're doing this year, you're gonna see more and more pricing changes from us. Yeah.swyx: And like is how much does stuff like VVC peering matter because you're working in AWS land where egress is charged and all that, you know.Simon Hørup Eskildsen: We probably don't like, we have like an enterprise plan that just has like a base fee because we haven't had time to figure out SKU pricing for all of this.Um, but I mean, yeah, you can run turbo puffer either in SaaS, right? That's what Cursor does. You can run it in a single tenant cluster. So it's just you. That's what Notion does. And then you can run it in, in, in BYOC where everything is inside the customer's VPC, that's what an for example, philanthropic does.swyx: What I'm hearing is that this is probably the best CRO job for somebody who can come in and,Simon Hørup Eskildsen: I mean,swyx: help you with this.Simon Hørup Eskildsen: Um, like Turbo Puffer hired, like, I don't know what, what number this was, but we had a full-time CFO as like the 12th hire or something at Turbo Puffer, um, I think I hear are a lot of comp.I don't know how they do it. Like they have a hundred employees and not a CFO. It's like having a CFO is like a runningswyx: business man. Like, you know,Simon Hørup Eskildsen: it's so good. Yeah, like money Mike, like he just, you know, just handles the money and a lot of the business stuff and so he came in and just hopped with a lot of the operational side of the business.So like C-O-O-C-F-O, like somewhere in between.swyx: Just as quick mention of Lucky, just ‘cause I'm curious, I've met Lock and like, he's obviously a very good investor and now on physical intelligence, um, I call it generalist super angel, right? He invests in everything. Um, and I always wonder like, you know, is there something appealing about focusing on developer tooling, focusing on databases, going like, I've invested for 10 years in databases versus being like a lock where he can maybe like connect you to all the customers that you need.Simon Hørup Eskildsen: This is an excellent question. No, no one's asked me this. Um, why lockey? Because. There was a couple of people that we were talking to at the time and when we were raising, we were almost a little, we were like a bit distressed because one of our, one of our peers had just launched something that was very similar to Turbo Puffer.And someone just gave me the advice at the time of just choose the person where you just feel like you can just pick up the phone and not prepare anything. And just be completely honest, and I don't think I've said this publicly before, but I just called Lockey and was like local Lockie. Like if this doesn't have PMF by the end of the year, like we'll just like return all the money to you.But it's just like, I don't really, we, Justine and I don't wanna work on this unless it's really working. So we want to give it the best shot this year and like we're really gonna go for it. We're gonna hire a bunch of people and we're just gonna be honest with everyone. Like when I don't know how to play a game, I just play with open cards and.Lockey was the only person that didn't, that didn't freak out. He was like, I've never heard anyone say that before. As I said, I didn't even know what a seed or pre-seed round was like before, probably even at this time. So I was just like very honest with him. And I asked him like, Lockie, have you ever have, have you ever invested in database company?He was just like, no. And at the time I was like, am I dumb? Like, but I think there was something that just like really drew me to Lockie. He is so authentic, so honest, like, and there was something just like, I just felt like I could just play like, just say everything openly. And that was, that was, I think that that was like a perfect match at the time, and, and, and honestly still is.He was just like, okay, that's great. This is like the most honest, ridiculous thing I've ever heard anyone say to me. But like that, like that, whyswyx: is this ridiculous? Say competitor launch, this may not work out. It wasSimon Hørup Eskildsen: more just like. If this doesn't work out, I'm gonna close up shop by the end of the mo the year, right?Like it was, I don't know, maybe it's common. I, I don't know. He told me it was uncommon. I don't know. Um, that's why we chose him and he'd been phenomenal. The other people were talking at the, at the time were database experts. Like they, you know, knew a lot about databases and Locke didn't, this turned out to be a phenomenal asset.Right. I like Justine and I know a lot about databases. The people that we hire know a lot about databases. What we needed was just someone who didn't know a lot about databases, didn't pretend to know a lot about databases, and just wanted to help us with candidates and customers. And he did. Yeah. And I have a list, right, of the investors that I have a relationship with, and Lockey has just performed excellent in the number of sub bullets of what we can attribute back to him.Just absolutely incredible. And when people talk about like no ego and just the best thing for the founder, I like, I don't think that anyone, like even my lawyer is like, yeah, Lockey is like the most friendly person you will find.swyx: Okay. This is my most glow recommendation I've ever heard.Alessio: He deserves it.He's very special.swyx: Yeah. Yeah. Yeah. Okay. Amazing.Alessio: Since you mentioned candidates, maybe we can talk about team building, you know, like, especially in sf, it feels like it's just easier to start a company than to join a company. Uh, I'm curious your experience, especially not being n SF full-time and doing something that is maybe, you know, a very low level of detail and technical detail.Simon Hørup Eskildsen: Yeah. So joining versus starting, I never thought that I would be a founder. I would start with it, like Turbo Puffer started as a blog post, and then it became a project and then sort of almost accidentally became a company. And now it feels like it's, it's like becoming a bigger company. That was never the intention.The intentions were very pure. It's just like, why hasn't anyone done this? And it's like, I wanna be the, like, I wanna be the first person to do it. I think some founders have this, like, I could never work for anyone else. I, I really don't feel that way. Like, it's just like, I wanna see this happen. And I wanna see it happen with some people that I really enjoy working with and I wanna have fun doing it and this, this, this has all felt very natural on that, on that sense.So it was never a like join versus versus versus found. It was just dis found me at the right moment.Alessio: Well I think there's an argument for, you should have joined Cursor, right? So I'm curious like how you evaluate it. Okay, I should actually go raise money and make this a company versus like, this is like a company that is like growing like crazy.It's like an interesting technical problem. I should just build it within Cursor and then they don't have to encrypt all this stuff. They don't have to obfuscate things. Like was that on your mind at all orSimon Hørup Eskildsen: before taking the, the small check from Lockie, I did have like a hard like look at myself in the mirror of like, okay, do I really want to do this?And because if I take the money, I really have to do it right. And so the way I almost think about it's like you kind of need to ha like you kind of need to be like fucked up enough to want to go all the way. And that was the conversation where I was like, okay, this is gonna be part of my life's journey to build this company and do it in the best way that I possibly can't.Because if I ask people to join me, ask people to get on the cap table, then I have an ultimate responsibility to give it everything. And I don't, I think some people, it doesn't occur to me that everyone takes it that seriously. And maybe I take it too seriously, I don't know. But that was like a very intentional moment.And so then it was very clear like, okay, I'm gonna do this and I'm gonna give it everything.Alessio: A lot of people don't take it this seriously. But,swyx: uh, let's talk about, you have this concept of the P 99 engineer. Uh, people are 10 x saying, everyone's saying, you know, uh, maybe engineers are out of a job. I don't know.But you definitely see a P 99 engineer, and I just want you to talk about it.Simon Hørup Eskildsen: Yeah, so the P 99 engineer was just a term that we started using internally to talk about candidates and talk about how we wanted to build the company. And you know, like everyone else is, like we want a talent dense company.And I think that's almost become trite at this point. What I credit the cursor founders a lot with is that they just arrived there from first principles of like, we just need a talent dense, um, talent dense team. And I think I've seen some teams that weren't talent dense and like seemed a counterfactual run, which if you've run in been in a large company, you will just see that like it's just logically will happen at a large company.Um, and so that was super important to me and Justine and it's very difficult to maintain. And so we just needed, we needed wording for it. And so I have a document called Traits of the P 99 Engineer, and it's a bullet point list. And I look at that list after every single interview that I do, and in every single recap that we do and every recap we end with.End with, um, some version of I'm gonna reject this candidate completely regardless of what the discourse was, because I wanna see people fight for this person because the default should not be, we're gonna hire this person. The default should be, we're definitely not hiring this person. And you know, if everyone was like, ah, maybe throw a punch, then this is not the right.swyx: Do, do you operate, like if there's one cha there must have at least one champion who's like, yes, I will put my career on, on, on the line for this. You know,Simon Hørup Eskildsen: I think career on the line,swyx: maybe a chair, butSimon Hørup Eskildsen: yeah. You know, like, um, I would say so someone needs to like, have both fists up and be like, I'd fight.Right? Yeah. Yeah. And if one person said, then, okay, let's do it. Right?swyx: Yeah.Simon Hørup Eskildsen: Um. It doesn't have to be absolutely everyone. Right? And like the interviews are always the sign that you're checking for different attributes. And if someone is like knocking it outta the park in every single attribute, that's, that's fairly rare.Um, but that's really important. And so the traits of the P 99 engineer, there's lots of them. There's also the traits of the p like triple nine engineer and the quadruple nine engineer. This is like, it's a long list.swyx: Okay.Simon Hørup Eskildsen: Um, I'll give you some samples, right. Of what we, what we look for. I think that the P 99 engineer has some history of having bent, like their trajectory or something to their will.Right? Some moment where it was just, they just, you know, made the computer do what it needed to do. There's something like that, and it will, it will occur to have them at some point in their career. And, uh. Hopefully multiple times. Right.swyx: Gimme an example of one of your engineers that like,Simon Hørup Eskildsen: I'll give an eng.Uh, so we, we, we launched this thing called A and NV three. Um, we could, we're also, we're working on V four and V five right now, but a and NV three can search a hundred billion vectors with a P 50 of around 40 milliseconds and a p 99 of 200 milliseconds. Um, maybe other people have done this, I'm sure Google and others have done this, but, uh, we haven't seen anyone, um, at least not in like a public consumable SaaS that can do this.And that was an engineer, the chief architect of Turbo Puffer, Nathan, um, who more or less just bent this, the software was not capable of this and he just made it capable for a very particular workload in like a, you know, six to eight week period with the help of a lot of the team. Right. It's been, been, there's numerous of examples of that, like at, at turbo puff, but that's like really bending the software and X 86 to your will.It was incredible to watch. Um. You wanna see some moments like that?swyx: Isn't that triple nine?Simon Hørup Eskildsen: Um, I think Nathan, what's calledAlessio: group nine, that was only nine. I feel like this is too high forSimon Hørup Eskildsen: Nathan. Nathan is, uh, Nathan is like, yeah, there's a lot of nines. Okay. After that p So I think that's one trait. I think another trait is that, uh, the P 99 spends a lot of time looking at maps.Generally it's their preferred ux. They just love looking at maps. You ever seen someone who just like, sits on their phone and just like, scrolls around on a map? Or did you not look at maps A lot? You guys don't look atswyx: maps? I guess I'm not feeling there. I don't know, butSimon Hørup Eskildsen: you just dis What about trains?Do you like trains?swyx: Uh, I mean they, not enough. Okay. This is just like weapon nice. Autism is what I call it. Like, like,Simon Hørup Eskildsen: um, I love looking at maps, like, it's like my preferred UX and just like I, you know, I likeswyx: lotsAlessio: of, of like random places, soswyx: like,youswyx: know.Alessio: Yes. Okay. There you go. So instead of like random places, like how do you explore the maps?Simon Hørup Eskildsen: No, it's, it's just a joke.swyx: It's autism laugh. It's like you are just obsessed by something and you like studying a thing.Simon Hørup Eskildsen: The origin of this was that at some point I read an interview with some IOI gold medalistswyx: Uhhuh,Simon Hørup Eskildsen: and it's like, what do you do in your spare time? I was just like, I like looking at maps.I was like, I feel so seen. Like, I just like love, like swirling out. I was like, oh, Canada is so big. Where's Baffin Island? I don't know. I love it. Yeah. Um, anyway, so the traits of P 99, P 99 is obsessive, right? Like, there's just like, you'll, you'll find traits of that we do an interview at, at, at, at turbo puffer or like multiple interviews that just try to screen for some of these things.Um, so. There's lots of others, but these are the kinds of traits that we look for.swyx: I'll tell you, uh, some people listen for like some of my dere stuff. Uh, I do think about derel as maps. Um, you draw a map for people, uh, maps show you the, uh, what is commonly agreed to be the geographical features of what a boundary is.And it shows also shows you what is not doing. And I, I think a lot of like developer tools, companies try to tell you they can do everything, but like, let's, let's be real. Like you, your, your three landmarks are here, everyone comes here, then here, then here, and you draw a map and, and then you draw a journey through the map.And like that. To me, that's what developer relations looks like. So I do think about things that way.Simon Hørup Eskildsen: I think the P 99 thinks in offs, right? The P 99 is very clear about, you know, hey, turbo puffer, you can't run a high transaction workload on turbo puffer, right? It's like the right latency is a hundred milliseconds.That's a clear trade off. I think the P 99 is very good at articulating the trade offs in every decision. Um. Which is exactly what the map is in your case, right?swyx: Uh, yeah, yeah. My, my, my world. My world.Alessio: How, how do you reconcile some of these things when you're saying you bend the will the computer versus like the trade

In this episode, I was lucky enough to interview Carl Gould, co-founder and CTO of Inductive Automation.Growing up in California's Bay Area during the rise of the modern internet, Carl developed an early fascination with computers that eventually led him to study computer science at UC Davis. What began as a summer project connecting industrial machine data to SQL databases soon evolved into a full software platform used by engineers around the world to build applications that monitor and control factories, water systems, and other industrial operations.Carl shares the story behind Inductive Automation's earliest days, including how mentorship from industry veteran Steve Heckman helped shape their understanding of the market and how their first independent customer—a project at Sierra Nevada Brewing Company—validated the idea that their solution solved a widespread industry gap. Along the way, Carl reflects on building a company from the ground up, the value of staying close to users, and why solving a real problem matters far more than chasing technology trends. More than two decades later, he remains energized by seeing what engineers create with Ignition and by staying connected to the people whose work the software powers every day.Explore how Carl Gould helped modernize industrial software by focusing on real problems engineers face in this episode of The First Customer!Guest Info:Inductive Automationhttp://www.inductiveautomation.comCarl Gould's LinkedInhttps://www.linkedin.com/in/carl-gould/Connect with Jay on LinkedInhttps://www.linkedin.com/in/jayaigner/The First Customer Youtube Channelhttps://www.youtube.com/@thefirstcustomerpodcastThe First Customer podcast websitehttps://www.firstcustomerpodcast.comFollow The First Customer on LinkedInhttp://www.linkedin.com/company/the-first-customer-podcast/

SQL Server 2025 is released - what's in it, and what happens next? Richard chats with Bob Ward about the huge array of announcements coming out of Ignite around SQL Server 2025, including AI-related features, new reliability and performance options, engine improvements, and more! The tooling for SQL Server also continues to evolve, including making Copilot available through SSMS and as part of the SQL extension to Visual Studio Code. And there's more to come - have a listen!LinksSQL Server 2025SQL Server 2025 UnveiledSSMS with Erin StellatoSQL Server Management StudioJSON Data in SQL ServerManaged Identity for SQL ServerSQL Server in Microsoft FabricMirroring SQL Server in FabricNext-Generation SQL Managed InstanceMSSQL Extension for Visual Studio CodeRecorded January 5, 2026

This is episode 319 recorded on February 6th, 2026, where John and Jason break down the Microsoft Fabric January 2026 Feature Summary — including the Osmos acquisition for AI-ready data engineering, Git branch improvements and Python SDK support for the Fabric API, expanded OneLake security, and new Real-Time Intelligence enhancements. For show notes please visit www.bifocal.show

Guy and Eitan talk about Erik Darling's new monitoring app, which reminds us of similar tools we had experience with long ago. And, again, it's time to talk about AI. Specifically, a side-effect of it called "The Liar's Dividend". Relevant links for more information: Free SQL Server Performance Monitor App by Erik Darling - Brent Ozar Unlimited® Free SQL Server Performance Monitoring | Darling Data The Liar's Dividend - When Nothing Is True, Everything Is Permitted - Eitan Blumin's blog Dear Copilot, can you help me with SQL? - Azure SQL Dev Corner Public Preview - Data Virtualization for Azure SQL Database | Microsoft Community Hub

This Podcast is sponsored by Team Simmer. Go to TeamSimmer and use the coupon code DEVIATE for 10% on individual course purchases. The Technical Marketing Handbook provides a comprehensive journey through technical marketing principles. Sign up to the Simmer Newsletter for the latest news in Technical Marketing. NEW SIMMER COURSE ALERT!  - Data Analysis with R - taught by Arben Kqiku  Latest content from Simo Ahava Run Server-side Google Tag Manager On Localhost Article Latest content from Juliana Jackson  Agent social networks are just a hall of mirrors (subscribe to the newsletter for more amazing content) Mentioned in the episode: Matomo Tag Piper by David Vallejo Walker OS Jason Packer's new book: Google Analytics Alternatives Superweek Analytics Summit Measurecamp Helsinki Connect with Johan: Linkedin GA4BigQuery GA4Dataform This podcast is brought to you by Juliana Jackson and Simo Ahava.

Nik and Michael discuss query plan flips in Postgres — what they are, some causes, mitigations, longer term solutions, and the recent outage at Clerk. Here are some links to things they mentioned: Recent postmortem from Clerk https://clerk.com/blog/2026-02-19-system-outage-postmortemThe real cost of random I/O (blog post by Tomas Vondra) https://vondra.me/posts/the-real-cost-of-random-ioautovacuum_analyze_scale_factor https://www.postgresql.org/docs/current/runtime-config-vacuum.html#GUC-AUTOVACUUM-ANALYZE-SCALE-FACTORdefault_statistics_target https://www.postgresql.org/docs/current/runtime-config-query.html#GUC-DEFAULT-STATISTICS-TARGETpg_hint_plan https://github.com/ossc-db/pg_hint_planAurora PostgreSQL query plan management https://docs.aws.amazon.comAmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Optimize.Start.htmlpg_stat_plans https://github.com/pganalyze/pg_stat_planspg_plan_alternatives https://jnidzwetzki.github.io/2026/03/04/pg-plan-alternatives.htmlWaiting for Postgres 19: Better Planner Hints with Path Generation Strategies https://pganalyze.com/blog/5mins-postgres-19-better-planner-hints~~~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 credit to:Jessie Draws for the elephant artwork

“Skończyły się czasy romantycznego IT - to jest taka sama praca jak każda inna, 9-17 i ludzie chcą wrócić do swojego życia.” Łukasz otwiera odcinek o zarządzaniu zespołem najbrutalniej jak się da - bo Kuba zapytał na Discordzie: “czemu to trwa tydzień, jak ja bym zrobił w kilka godzin?” Łukasz dodaje twist: “Jesteście bardzo niereprezentatywną próbką osób pracujących obecnie w IT.”

Will Madden joins the podcast to talk about Prisma Next and the evolution from Prisma 7, including the decision to migrate away from Rust, ship the core through WebAssembly, and move toward a fully TypeScript ORM. The conversation dives into how modern workflows like agentic coding change the role of an ORM and why tools still matter even when agents can write SQL queries directly. We discuss how feedback loops, guardrails, and the TypeScript type system help prevent errors, along with the new query builder, query linter, and middleware layer that analyze queries using an abstract syntax tree. The episode also covers new database capabilities including Postgres support, upcoming Mongo support, and extensions like PG Vector, enabling vector columns and cosine distance similarity search. You'll also learn about new patterns such as collection methods, scopes, and composable database extensions, plus tooling like driver adapters, a potential compatibility layer, and safeguards like lint rules and a performance budget middleware designed to catch expensive queries before they run. Resources The Next Evolution of Prisma ORM: https://www.prisma.io/blog/the-next-evolution-of-prisma-orm We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Fill out our listener survey! https://t.co/oKVAEXipxu Let us know by sending an email to our producer, Elizabeth, at elizabeth.becz@logrocket.com, or tweet at us at PodRocketPod. Check out our newsletter! https://blog.logrocket.com/the-replay-newsletter/ Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form, and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understanding where your users are struggling by trying it for free at LogRocket.com. Try LogRocket for free today. Chapters 00:00 Introduction 01:00 Prisma Seven and the Move Away from Rust 02:20 Missing Features and Mongo Support 03:00 Why Prisma Started Rebuilding the Core 04:00 Community Sentiment and Developer Feedback 05:20 Rethinking ORMs in the AI and Agentic Coding Era 06:45 Why Agents Still Need ORMs 07:30 Feedback Loops and Guardrails for SQL 08:30 Type Safety and the First Layer of Query Validation 09:30 Query Linter and Middleware Architecture 11:00 Runtime Validation and Query Errors 12:30 Configuring Lint Rules and Guardrails 14:00 Designing ORMs for Humans and Agents 15:30 Collection Methods and ActiveRecord-style Scopes 17:00 Reusable Queries and Domain Vocabulary 18:30 Query Composition and Flexibility 19:00 Performance Guardrails and Query Budget Middleware 20:30 Debugging ORM Performance Issues 21:00 Query Telemetry and Request Tracing 22:30 Prisma Next Extensibility and Database Plugins 23:00 Using PGVector and Vector Search 24:00 Database Drivers and Backend Architecture 25:00 Native Mongo Support in Prisma Next 26:00 Community Extensions and Middleware Ecosystem 27:00 Runtime Schema Validation Use Cases 28:00 Writing Custom Query Validation Rules 29:00 Migration Paths from Prisma Seven 30:30 Compatibility Layers vs Parallel Systems 32:00 Prisma Next Roadmap and Timeline 34:30 What Developers Will Be Most Excited About 35:30 Final Thoughts and Community Feedback

In this episode of Manufacturing Hub, Vlad and Dave sit down with Travis Cox and Kevin McCluskey from Inductive Automation to unpack what was actually proven at ProveIt and why it matters for teams trying to modernize plants without building a fragile mess of point to point integrations. If you have ever looked at a shiny demo and wondered what the real architecture looks like, how it scales beyond a single line, and what it takes to roll out across multiple sites without turning every change into a high risk event, this conversation is for you.Travis and Kevin walk through their ProveIt Enterprise B build and the thinking behind it. The core idea is simple but powerful: treat the factory like a system that needs a shared digital infrastructure, built on open standards, where data is contextualized and reusable. They break down how they used Ignition Edge close to PLCs for resiliency, local HMIs, and disciplined data modeling, then moved data through MQTT into a Unified Namespace so multiple applications can consume the same trusted signals and context. This is the difference between “we can connect to anything” and “we can scale without rewriting everything every time the business changes.” Open standards show up repeatedly in the conversation because ProveIt is specifically designed to force interoperability and practical implementation tradeoffs. Inductive Automation has also written about ProveIt as a place where MQTT, OPC UA, and SQL show up as real foundations rather than slogans.From there, the episode gets into the part that should make both OT and IT teams pay attention: modern deployment practices applied to industrial applications. Kevin outlines a clear maturity path from a single designer workflow to version control, then to containerized deployments, and finally to full GitOps style promotion across dev, staging, and production using tools like Argo CD, Helm, Kubernetes, and release promotion concepts that look like what the software world has used for years. Argo CD is explicitly built around Git repositories as the source of truth for desired state, which is exactly why it fits this style of deployment. The live portion of the conversation demonstrates how fast this can get when the infrastructure is treated as code: they spin up a brand new “site four” by submitting a form, generating a pull request, merging it, and letting the pipeline do the rest.Timestamps00:00 Welcome back and why this ProveIt recap matters01:35 Meet Travis Cox and Kevin McCluskey from Inductive Automation03:10 What ProveIt is and the key vendor questions it forces05:20 Enterprise B architecture overview from PLC to Edge to site to enterprise07:30 HMI walkthrough across liquid processing, filling, packaging, palletizing09:05 Why deploy Ignition Edge instead of only a centralized site gateway12:05 Design once, reuse everywhere and what that means for scaling quickly14:35 On prem realities versus cloud infrastructure in the ProveIt environment17:10 MCP, n8n workflows, and bringing live operational context into AI20:40 i3X style API access to models, history, and alarms for interoperability23:15 GitHub, Docker Compose, Helm, Kubernetes, Argo CD, Cargo and GitOps promotion36:55 Spinning up a new site live and what it changes for multi site rolloutsAbout the hostsVlad Romanov is an electrical engineer and MBA who has spent over a decade building and modernizing manufacturing systems across industrial automation, controls, and plant operations. Through Joltek, Vlad works with manufacturers to assess current state OT foundations, reduce modernization risk, improve reliability, and build internal capability through practical training and standards that stick.Dave Griffith co hosts Manufacturing Hub and brings a practitioner lens focused on what works on the plant floor, how architectures survive real constraints, and how industrial teams can modernize without breaking production.About the guestsTravis Cox is Chief Technology Evangelist at Inductive Automation and has spent over two decades helping customers and partners design scalable architectures, apply best practices, and deliver real solutions with Ignition.Kevin McCluskey is Chief Technology Architect at Inductive Automation and works with organizations on architecture decisions, platform direction, and enabling the next generation of industrial applications.Learn more about Joltekhttps://www.joltek.com/serviceshttps://www.joltek.com/book-a-modernization-consultation

Today, we're joined by Pete Hunt, CEO at Dagster Labs, building out Dagster, the data orchestration platform built for productivity. We talk about:Challenges of determining software pricing with AI workers using appsHow barriers to AI adoption are similar to what we've known in SaaS for a million yearsAI-driven shifts in the workplace [Many disciplines will look a lot more like engineering]How outside sales is among the most durable job functions in the AI eraAdvice for new college grads

This is episode 318 recorded on February 6th, 2026, where John and Jason break down the Power BI January 2026 Feature Update — covering the key report, model, and service changes, what's actually impactful, and how it fits into the broader Microsoft Fabric roadmap. For show notes please visit www.bifocal.show

This interview was recorded for GOTO Unscripted.https://gotopia.techCheck out more here:https://gotopia.tech/articles/421Félix GV - Current Interests: Multi-Planetary Databases, Data Sovereignty & LifeloggingOlimpiu Pop - Technologist & Tech JournalistRESOURCESFélixhttps://bsky.app/profile/felixgv.ninjahttps://github.com/FelixGVhttps://www.linkedin.com/in/felixgvOlimpiuhttps://x.com/olimpiupophttps://github.com/zrollhttps://www.linkedin.com/in/olimpiupopLinkshttps://venicedb.orghttps://github.com/linkedin/venicehttps://rocksdb.orghttps://duckdb.orgDESCRIPTIONFélix GV, a former engineer at LinkedIn and architect of the Venice database system, discusses the complexity of building planetary-scale data systems. He explains Venice's unbundled architecture where each component—from Kafka-based pub/sub to RocksDB-powered servers—operates as an independent distributed system. Félix details their rigorous chaos engineering practices, including regular load tests that push data centers beyond normal capacity to ensure reliability.The discussion covers fundamental distributed systems concepts like the CAP theorem and the trade-offs between consistency and availability in multi-region deployments. He also explains why Venice, as a derived data system, deliberately sacrifices strong consistency for high throughput and availability, and concludes by discussing their experimental integration of DuckDB for SQL-based analytics and data exploration capabilities.RECOMMENDED BOOKSKasun Indrasiri & Danesh Kuruppu • gRPC: Up and Running • https://amzn.to/3sBGBJJTomer Shiran, Jason Hughes & Alex Merced • Apache Iceberg: The Definitive Guide • https://amzn.to/488Z30kWilliam Smith • Arrow Flight Protocols and Practices • https://amzn.to/4o2Q2fdAdi Polak • Scaling Machine Learning with Spark • https://amzn.to/3N9vx1HMark Needham, Michael Hunger & Michael Simons • DuckDB in Action • https://amzn.to/45QwSliSimon Aubury & Ned Letcher • Getting Started with DuckDB • https://amzn.to/3VPk4qBlueskyInstagramLinkedInFacebookCHANNEL MEMBERSHIP BONUSJoin this channel to get early access to videos & other perks:https://www.youtube.com/channel/UCs_tLP3AiwYKwdUHpltJPuA/joinLooking for a unique learning experience?Attend the next GOTO conference near you! Get your ticket: gotopia.techSUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

Would you like to take your search in SQL Server to the next level? In this episode, check out how to use vector search, securely built into SQL Server 2025. #sqlserver2025 #sqlai Chapters 00:00 - Introduction 01:10 - Evolution of SQL 02:44 - Intelligent searching with SQL and AI 06:16 - Model definition 08:55 - Generate embeddings 13:19 - Vector index 15:25 - Vector Search 17:50 - Azure OpenAI 19:36 - Wrap up Recommended resources Announcement Sign-up Learn Docs Product page Connect Scott Hanselman | Twitter/X: @SHanselman Bob Ward | Twitter/X: @bobwardms Azure Friday | Twitter/X: @AzureFriday Azure | Twitter/X: @Azure

Would you like to take your search in SQL Server to the next level? In this episode, check out how to use vector search, securely built into SQL Server 2025. #sqlserver2025 #sqlai Chapters 00:00 - Introduction 01:10 - Evolution of SQL 02:44 - Intelligent searching with SQL and AI 06:16 - Model definition 08:55 - Generate embeddings 13:19 - Vector index 15:25 - Vector Search 17:50 - Azure OpenAI 19:36 - Wrap up Recommended resources Announcement Sign-up Learn Docs Product page Connect Scott Hanselman | Twitter/X: @SHanselman Bob Ward | Twitter/X: @bobwardms Azure Friday | Twitter/X: @AzureFriday Azure | Twitter/X: @Azure

In this talk, Juan, Analytics Engineer and author of Fundamentals of Analytics Engineering share his professional journey from studying psychological research in Colombia to becoming one of the first analytics engineers in the Netherlands. We explore the evolution of the role, the shift toward engineering rigor in data modeling, and how the landscape of tools like dbt and Databricks is changing the way teams work.You'll learn about:- The fundamental differences between traditional BI engineering and modern analytics engineering.- How to bridge the gap between business stakeholders and technical data infrastructure.- The technical "glue" that connects Python and SQL for robust data pipelines.- The importance of automated testing (generic vs. singular tests) to prevent "silent" data failures.- Strategies for modeling messy, fragmented source data into a unified "business reality."- The current state of the "Lakehouse" paradigm and how it impacts storage and compute costs.- Expert advice on navigating the dbt ecosystem and its emerging competitors.Links:- DE Course: https://github.com/DataTalksClub/data-engineering-zoomcamp- Luma: https://luma.com/0uf7mmupTIMECODES:0:00 Juan's psychological research and transition to data4:36 Riding the wave: The early days of analytics engineering7:56 Breaking down the gap between analysts and engineers11:03 The art of turning business reality into clean data16:25 Why data engineering is about safety, not just speed20:53 Reimagining data modeling in the modern era26:53 To split or not to split: Finding the right team roles30:35 Python, SQL, and the technical toolkit for success38:41 How to stop manually testing your data dashboards46:34 Bringing software engineering rigor to data workflows49:50 Must-read books and resources for mastering the craft55:42 The future of dbt and the shifting tool landscape1:00:29 Deciphering the lakehouse: Warehousing in the cloud1:11:16 Pro-tips for starting your data engineering journey1:14:40 The big debate: Databricks vs. Snowflake1:18:28 Why every data professional needs a local communityThis talk is designed for data analysts looking to level up their engineering skills, data engineers interested in the business-logic layer, and data leaders trying to structure their teams more effectively. It is particularly valuable for those preparing for the Data Engineering Zoomcamp or anyone looking to transition into an Analytics Engineering role.Connect with Juan- Linkedin - https://www.linkedin.com/in/jmperafan/ - Website - https://juanalytics.com/Connect with DataTalks.Club:- Join the community - https://datatalks.club/slack.html- Subscribe to our Google calendar to have all our events in your calendar - https://calendar.google.com/calendar/r?cid=ZjhxaWRqbnEwamhzY3A4ODA5azFlZ2hzNjBAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ- Check other upcoming events - https://lu.ma/dtc-events- GitHub: https://github.com/DataTalksClub- LinkedIn - https://www.linkedin.com/company/datatalks-club/ - Twitter - https://twitter.com/DataTalksClub - Website - https://datatalks.club/

“Dla większości jest tak przekombinowany, że szkoda Waszego życia, żeby go sprawdzać.” Łukasz otwiera odcinek o Crossplane najbrutalniej jak się da - bo pod odcinkiem o chmurze w małej skali fani Kubernetesa zasugerowali “prawidłową automatyzację”. Szymon doprecyzowuje: “To ma dla mnie sens jak masz 100+ developerów.” Koszt? “Największym problemem jest to, że koszt ludzki utrzymania, zdobycia i zapewnienia kompetencji jest masakryczny.”

Patrick McKenzie (patio11) and Luke Farrell examine the structural "technical imagination" gap that prevents the US government from delivering high-fidelity digital services. They discuss why states routinely pay full price 29 times for the same buggy codebase, why failure is the default outcome, and why rooms full of government administrators cannot muster the expertise to say a two line code change should be trivial. They also discuss Luke's work on the "means testing industrial complex,” why the government redundantly pays a private vendor to do a SQL query for information the IRS already knows, and what vendors would say about their own discontents.–Full transcript available here: http://www.complexsystemspodcast.com/understanding-government-procurement-with-luke-farrell/–Presenting Sponsors: Mercury &  FramerIf you have more interesting hobbies than managing your money, Mercury Personal is built for you. It allows you to automate movement between accounts—allocating paychecks and tax prep the moment they hit—with a sensible permissions model for partners or accountants. It works the way tech people expect banking to work. Go to mercury.com/personal to experience banking built by the same folks Patrick trusts for his business. Mercury is a fintech company, not an FDIC-insured bank. Banking services provided through Choice Financial Group and Column N.A., Members FDIC.Building and maintaining marketing websites shouldn't slow down your engineers. Framer gives design and marketing teams an all-in-one platform to ship landing pages, microsites, or full site redesigns instantly—without engineering bottlenecks. Get 30% off Framer Pro at framer.com/complexsystems.–Links:Luke Farrell's Substack: https://donmoynihan.substack.com/Luke Farrell, The Means-Testing Industrial Complex: https://donmoynihan.substack.com/p/the-means-testing-industrial-complex–Timestamps:(00:00) Intro(01:52) Transitioning from Google to the US Digital Service (USDS) (05:18) How rule buildup and administrative burdens create "Kafkaesque" mazes (08:21) Using diagrams and funnels to visualize benefit denials (11:49) Software logic errors that improperly kicked children off Medicaid (18:25) Why government payroll IT costs hundreds of millions of dollars (20:02) Sponsors: Mercury and Framer(22:02) How recursive legal requirements and DOD standards inflate IT scope (26:57) Market consolidation and the lack of competition in procurement (33:47) Aligning program administrator incentives with successful service delivery (36:03) Using in-house technologists to push back on vendor change orders (39:27) Shifting from "Big Bang" contracts to iterative, agile development (53:10) The moral incoherence of asset limits (01:11:36) Insourcing electronic income verification databases (01:16:56) Building public sector competence to manage modern technical risk (01:20:08) Wrap

Nik and Michael discuss pg_ash — a new tool (not extension!) from Nik that samples and stores wait events from pg_stat_activity. Here are some links to things they mentioned: pg_ash https://github.com/NikolayS/pg_ashpg_wait_sampling https://github.com/postgrespro/pg_wait_samplingAmazon RDS performance insights https://aws.amazon.com/rds/performance-insightsOur episode on wait events https://postgres.fm/episodes/wait-eventspg-flight-recorder https://github.com/dventimisupabase/pg-flight-recorderpg_profile https://github.com/zubkov-andrei/pg_profilepg_cron https://github.com/citusdata/pg_cron~~~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 credit to:Jessie Draws for the elephant artwork

Vincent Heuschling reçoit Hayssam Saleh, créateur de **Starlake**, une plateforme data open source française née de la factorisation de projets clients depuis 2017-2018. L'épisode intervient dans un contexte de consolidation du marché (rachat de DBT et de SQLMesh par Fivetran), qui invite à challenger les solutions établies.Starlake se distingue par une approche **entièrement déclarative** (YAML + SQL natif, sans Jinja) couvrant toute la chaîne data engineering : ingestion, transformation, orchestration et qualité des données. L'outil s'appuie sur les moteurs sous-jacents des plateformes cibles (Snowflake, BigQuery, Spark) et génère automatiquement les DAGs pour les orchestrateurs du marché (Airflow, Dagster, Snowflake Tasks).Parmi les fonctionnalités marquantes : le **data branching** (branches de données à la manière de Git), l'inférence automatique de schémas YAML à partir de fichiers sources, un **transpiler SQL** multi-plateformes, et l'extraction du lineage depuis du SQL brut sans annotation. L'intégration récente de **DuckLake** ouvre la voie à des architectures on-premise souveraines à coût maîtrisé (sous 300 €/mois sur OVH, Scaleway, Clever Cloud).Le modèle économique repose sur le support, la formation, et le consulting : Starlake s'installe dans le cloud du client, avec mise à jour automatique gérée par l'équipe, sans accès aux données.**Chapitres****00:00:27** – Introduction : consolidation du marché data (rachat de DBT et SQLMesh par Fivetran) et présentation de l'épisode**00:03:13** – Hayssam et la genèse de Starlake : parcours Spark/Scala, POC à 4 000 formats de fichiers (2017-2018)**00:09:51** – Architecture et philosophie : load, transform, orchestration unifiés en déclaratif (YAML + SQL natif, pas de Jinja)**00:00:18:18** – Starlake vs DBT : différences philosophiques, composabilité, fonctionnalités 100 % open source**00:00:22:20** – Data branching, Starlake Labs (pipe syntax, transpiler SQL, lineage) et expérience développeur (DuckDB local, UI point-and-click)**00:36:35** – Modèle open source et économique : licence Apache, support, formation, marketplace cloud souveraine**00:43:42** – DuckLake : alternative on-premise/cloud souverain (OVH, Scaleway, Clever Cloud) et comment contribuer / démarrer**Le BigdataHebdo**Le BigdataHebdo est le podcast Francophone de la Data et de l'IA.Retrouvez plus de 200 épisodes https://bigdatahebdo.comRejoignez la communauté sur le Slack https://join.slack.com/t/bigdatahebdo/shared_invite/zt-a931fdhj-8ICbl9dbsZZbTcze61rr~Q

Your email gateway isn't enough anymore, attackers are already inside the workspace through OAuth apps, browser extensions, and account takeover.  In this episode, Ron sits down with Rajan Kapoor, VP of Security at Material Security, to break down the real risks hiding inside Google Workspace and Microsoft 365. They cover how phishing has evolved into full-blown business email compromise, why malicious OAuth apps are the new favorite attack vector, and what security teams, especially lean ones, can do right now to lock down their cloud workspace. Rajan also drops practical advice on passkeys, document sharing hygiene, and why data lifecycle management is a problem no one is solving well enough. Impactful Moments 00:00 – Introduction 03:30 – The current state of phishing 05:30 – Outbound email compromise risk 09:30 – OAuth apps as attack vectors 15:00 – AI agents accessing your workspace 16:00 – Prompt injection is the new SQL injection 18:00 – Allow listing apps immediately 24:30 – Google Workspace vs Microsoft 365 security 27:30 – Custom detections require API expertise 28:00 – Why passkeys matter right now 32:00 – Data lifecycle management for shared docs Links Connect with our guest, Rajan Kapoor, on LinkedIn: https://www.linkedin.com/in/rajankkapoor/ Learn more about Material Security: https://material.security  ___ Become a sponsor of the show to amplify your brand: https://hackervalley.com/work-with-us/ Check out our upcoming events: https://www.hackervalley.com/livestreams  Love Hacker Valley Studio? Pick up some swag: https://store.hackervalley.com   

Send a textImagine an autonomous agent that dreams up a business, raises funds, ships code, and starts earning—all without a human in the loop. That's no longer sci‑fi. We sit down with Rodrigo Coelho to map the rails that make it plausible: reliable blockchain data, open payment standards, and human‑grade controls that keep machine spenders on track.We start with a myth many still believe: blockchains are easy to read. Rodrigo explains why they were write‑first, and how The Graph became a quiet backbone of DeFi by turning messy ledgers into queryable data. Years of running high‑throughput infrastructure set the stage for AMP, a SQL‑first, local‑first approach that unifies access across chains, runs on‑prem for banks, and proves that internal datasets match on‑chain truth—fuel for compliance, audit, and real‑world finance moving on blockchain rails.Then we connect the dots with AI. Leaders who once shrugged at crypto now see agents as the perfect fit: low fees, transparency, and observability. With X402 enabling open micropayments over HTTP, the next missing piece was control. Enter "ampersend", a dashboard and policy plane for agent wallets, spend limits, batching, and reputation‑aware routing. Think: “only transact with agents above a reputation threshold,” “cap this task at 50 cents,” or “enforce daily budgets,” all verifiable and auditable. We also unpack emerging standards like ERC‑8004 for reputation and the Advanced AI Society's proof of control, outlining the identity, trust, and policy stack enterprises need before they unleash agents at scale.By 2026, expect major institutions to settle on blockchain rails, blending privacy with auditability, and tokenizing everything from bonds to real estate. The opportunity is clear: give agents the autonomy to create value while giving humans the levers to define, observe, and verify. If you care about AI agents, Web3 data, enterprise compliance, and the future of payments, this conversation connects the technical dots to the business outcomes.Enjoyed the episode? Follow the show, share it with a friend who loves AI or Web3, and leave a 5‑star review to help more people find us.This episode was recorded through a Descript call on February 5, 2026. Read the blog article and show notes here: https://webdrie.net/how-ai-agents-will-spend-earn-and-prove-trust-on-blockchain-rails/..........................................................................

We know what the work of the data practitioner is, right? It's everything from managing data ingestion to data governance to report development to experimental design to basic and advanced analytics. It's writing (or vibe-writing?) SQL or Python or R while also being adept at whatever data stack—no matter how modern—is at hand. Of course, it's a lot more, too! And that's the topic of this episode: the unofficial, often unheralded, but often quite important "shadow work" of the analyst—the myriad tasks required to effectively glue together all the data work that occurs out in broad daylight to enable the data to truly be useful at driving the business forward. For complete show notes, including links to items mentioned in this episode and a transcript of the show, visit the show page.

ANTIC Episode 125 - "Combining SQL with Fun (and Poo)" In this episode of ANTIC The Atari 8-Bit Computer Podcast… Wade Ripkowski comes onto the show and gives us an update on his work to bring SQL to the Atari (and an extremely useful poo management tool!), we cover good news concerning the Curt Vendel Atari collection, we report on an exciting updated browser-based emulator, a huge update to AspeQT, and a whole lot more!! READY! Recurring Links  Floppy Days Podcast  AtariArchives.org  AtariMagazines.com  Kay's Book "Terrible Nerd"  New Atari books scans at archive.org  ANTIC feedback at AtariAge  Atari interview discussion thread on AtariAge  Interview index: here  ANTIC Facebook Page  AHCS  Eaten By a Grue  Next Without For  What we've been up to cubeSQL project blog post - https://unfinishedbitness.info/2026/02/01/atari-8-bit-sql/ Unfinished Bitness - https://unfinishedbitness.info Wade's A8 C Library - https://unfinishedbitness.info/c-library/ cubeSQL - https://sqlabs.com/cubesql FujiNet - https://fujinet.online/ CubeDot - https://unfinishedbitness.info/cubedot/ Fuji Do - https://unfinishedbitness.info/fuji-do/ Fuji Poo - https://unfinishedbitness.info/fuji-poo/ Dr. Love - https://unfinishedbitness.info/dr-love/ video demo of CubeDot - https://vimeo.com/1165039670 video demo of Fuji Do - https://vimeo.com/1165038947 Mr. Paint - https://unfinishedbitness.info/mr-paint/ King PONG How Atari Bounced Across Markets to Make Millions - https://mitpress.mit.edu/9780262051330/king-pong/  Atari newsletter time capsule 1987-08: https://archive.org/details/antc_Atari_newsletter_time_capsule_1987-08  The Strong museum - https://www.museumofplay.org/  FujiNet Application Ideas - https://github.com/FujiNetWIFI/fujinet-firmware/wiki/Application-Ideas  Smith Corona Messenger Module and Smith Corona Ultrasonic 450 typewriter -  https://typewriterdatabase.com/1983-smith-corona-ultrasonic.2181.typewriter  prototype of Atari chapter for Quick Reference Book - https://floppydaysqr.my.canva.site/  New & Updated Games Inufuto Game Cartridge - posted by Philsan: https://forums.atariage.com/topic/331824-inufuto-does-atari-8-bit/page/5/#comment-5783007  https://www.atarimania.com/list_games_atari-400-800-xl-xe-inufuto_developer_3171_8_G.html  FujiNet Midimaze mode now stable by Mozzwald - https://forums.atariage.com/topic/387536-midimaze-mode-now-stable/  New & Updated non-Game Software A8E (Atari 800 XL Emulator) - By AnimaInCorpore: https://forums.atariage.com/topic/388191-a8e-atari-800-xl-emulator-v100/  Source - https://github.com/AnimaInCorpore/A8E  Browser demo - https://jsa8e.anides.de/  Atari800-AI - Benj Edwards - https://github.com/benj-edwards/atari800-ai  Update to mkatr (including lsatr) tools from dmsc - https://github.com/dmsc/mkatr/releases/tag/v1.4   AspeQt-2k26 - John Paul Jones: https://github.com/pjones1063/AspeQt-2k26  https://forums.atariage.com/topic/387630-wip-aspeqt-2k26-resurrecting-aspeqt-with-qt6-high-dpi-wi-fi-modems/  https://forums.atariage.com/topic/388105-%F0%9F%9A%80-aspeqt-2k26-dev-update-the-thin-client-concept-introducing-the-w-device-and-clipboard-y-device/  Publications BASIC Fun on Your A400 Mini: BASIC for real hardware and emulators too!  By John McGinnis - https://www.amazon.com/BASIC-Fun-Your-A400-Mini/dp/B0G1YGJ2P7  Atari Insights February 2026: Newsletters - https://ataribasics.com/newsletter-hub/  YouTube channel - https://www.youtube.com/@AtariBasics  February, 2026 Issue of Compute's Gazette - https://www.computesgazette.com  ABBUC Magazine 163 released - https://www.abbuc.de  Pro(c) gone; last issue #15 - web site updated May 2025 - https://web.archive.org/web/20250404175246/https://proc-atari.de/ New & Updated Hardware  5200XEGS - Making your Classic Super Game Console into an 8-Bit Computer - mytek - https://forums.atariage.com/topic/387340-5200xegs-making-your-classic-super-game-console-into-an-8-bit-computer/  Contests High Score Club active for 2026 (season 23) - https://forums.atariage.com/topic/387353-hsc-season-23-jan-2026-welcome-and-game-list-thread/  ABBUC Creative Competition 2026 has been launched - https://forums.atariage.com/topic/387746-abbuc-creative-competition-2026-has-been-launched/  ABBUC Application Software Competition 2026 has been launched - https://forums.atariage.com/topic/387745-abbuc-application-software-competition-2026-has-been-launched/  ABBUC Game Software Competition 2026 has been launched - https://forums.atariage.com/topic/387744-abbuc-software-competition-2026-has-been-launched/  ABBUC Hardware Competition 2026 has been launched - https://forums.atariage.com/topic/387737-abbuc-hardware-competition-2026-has-been-launched/   Other Byte magazine cover illustrator has passed away. https://tinney.net/in-memoriam  Strong museum announces the acquisition of the Curt Vendel Atari Collection - https://www.museumofplay.org/press-release/the-strong-national-museum-of-play-acquires-atari-home-computer-and-console-division-collection/  Atari Hotel news - https://www.casino.org/vitalvegas/atari-hotel-that-was-never-happening-makes-headlines-for-not-happening/  Upcoming Shows (thru May, 2026) Indy Classic Computer and Video Game Expo - March 20-22 - Wyndham Indianapolis Airport Hotel, Indianapolis, IN - https://indyclassic.org/  Atari Invasion 2k26 (10th Anniversary) - March 21 - Maarssen, Netherlands - https://www.atari-invasion.nl  VCF East - April 17-19 2026 - InfoAge Science and History Museums, Wall, NJ - https://vcfed.org/events/vintage-computer-festival-east/  Midwest Gaming Classic - April 24-26 - Baird Center, Milwaukee, WI - https://www.midwestgamingclassic.com/  VCF Europe - May 1-3 - Munich, Germany - https://vcfe.org/E/  Vintage Computer Festival Pacific Northwest 2026 - May 2-3 - Tukwila Community Center, South Tukwila, WA -  https://vcfpnw.org  VCF Southwest - May 29-31, 2026 - Westin Dallas Ft. Worth Airport - https://www.vcfsw.org/  Retrofest 2026 - May 30-31 - Steam Museum of the Great Western Railway, Swindon, UK - https://retrofest.uk/   YouTube Videos Atari 130XE gets new ACID Stereo board (with new U1MB plugin), Decent XE keyboard, and more upgrades - FlashJazzCat - https://www.youtube.com/watch?v=XRjy-0AB_90  Using FujiNet NOS with SD Card - Thom Cherryhomes - https://youtu.be/G0gXB3Z4Nmc  Feedback Beat The Beatles — "It May Be The First Video Game About The Beatles" - Before Rock Band, There Was Beat the Beatles - https://www.timeextension.com/news/2025/11/random-it-may-be-the-first-video-game-about-the-beatles-before-rock-band-there-was-beat-the-beatles  Wade Ripkowski Contact Information https://inverseatascii.info/ https://unfinishedbitness.info/ Mastodon @inverseatascii@techhub.social Email: inverseatascii@icloud.com   

Martin Casado speaks with Ankur Goyal, founder and CEO of Braintrust, about where engineering actually matters in AI and where it doesn't. They cover the open source vs closed source model cycle, why Chinese models are gaining ground faster than spending suggests, whether AI demand will eventually saturate, and the Bash vs SQL benchmark that challenges the "just give it a computer" approach to agents.Follow Martin Casado on X: https://twitter.com/martin_casadoFollow Ankur Goyal on X: https://twitter.com/ankrgyl Check out everything a16z is doing with artificial intelligence here, including articles, projects, and more podcasts. Please note that the content here is for informational purposes only; should NOT be taken as legal, business, tax, or investment advice or be used to evaluate any investment or security; and is not directed at any investors or potential investors in any a16z fund. a16z and its affiliates may maintain investments in the companies discussed. For more details please see a16z.com/disclosures. Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.

Kennst du diese Situation im Team: Jemand sagt "das skaliert nicht", und plötzlich steht der Datenbankwechsel schneller im Raum als die eigentliche Frage nach dem Warum? Genau da packen wir an. Denn in vielen Systemen entscheidet nicht das nächste hippe Tool von Hacker News, sondern etwas viel Grundsätzlicheres: Datenlayout und Zugriffsmuster.In dieser Episode gehen wir einmal tief runter in den Storage-Stack. Wir schauen uns an, warum Row-Oriented-Datastores der Standard für klassische OLTP-Workloads sind und warum "SELECT id" trotzdem oft fast genauso teuer ist wie "SELECT *". Danach drehen wir die Tabelle um 90 Grad: Column Stores für OLAP, Aggregationen über viele Zeilen, Spalten-Pruning, Kompression, SIMD und warum ClickHouse, BigQuery, Snowflake oder Redshift bei Analytics so absurd schnell werden können.Und dann wird es file-basiert: CSV bekommt sein verdientes Fett weg, Apache Parquet seinen Hype, inklusive Row Groups, Metadaten im Footer und warum das für Streaming und Object Storage so gut passt. Mit Apache Iceberg setzen wir noch eine Management-Schicht oben drauf: Snapshots, Time Travel, paralleles Schreiben und das ganze Data-Lake-Feeling. Zum Schluss landen wir da, wo es richtig weh tut, beziehungsweise richtig Geld spart: Storage und Compute trennen, Tiered Storage, Kafka Connect bis Prometheus und Observability-Kosten.Wenn du beim nächsten "das skaliert nicht" nicht direkt die Datenbank tauschen willst, sondern erst mal die richtigen Fragen stellen möchtest, ist das deine Folge.Bonus: DuckDB als kleines Taschenmesser für CSV, JSON und SQL kann dein nächstes Wochenend-Experiment werden.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

This week we're joined by Joel Griffith, the founder and CEO of Browserless. Browserless is a browser automation service that allows you to run headless browsers in the cloud. We talk about the challenges of running headless browsers at scale, the use cases for browser automation, and the future of browser automation. We also discuss the BrowserQL feature, which allows you to query the web using a SQL-like language.Website: browserless.ioDocumentation: docs.browserless.ioGitHub: github.com/browserless/browserless (12.3k stars)GitHub (Personal): github.com/joelgriffithTwitter/X: @browserlessLinkedIn: Joel Griffith

Nik and Michael discuss query level comments, object level comments, and another way of adding object level metadata. Here are some links to things they mentioned: Object comments https://www.postgresql.org/docs/current/sql-comment.htmlQuery comment syntax (from an old version of the docs) https://www.postgresql.org/docs/7.0/syntax519.htmSQL Comments, Please! (Post by Markus Winand) https://modern-sql.com/caniuse/comments“While C-style block comments are passed to the server for processing and removal, SQL-standard comments are removed by psql.” https://www.postgresql.org/docs/current/app-psql.htmlmarginalia https://github.com/basecamp/marginaliatrack_activity_query_size https://www.postgresql.org/docs/current/runtime-config-statistics.html#GUC-TRACK-ACTIVITY-QUERY-SIZECustom Properties for Database Objects Using SECURITY LABELS (post by Andrei Lepikhov) https://www.pgedge.com/blog/custom-properties-for-postgresql-database-objects-without-core-patches~~~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 credit to:Jessie Draws for the elephant artwork

Vincent Warmerdam is a Founding Engineer at marimo, working on reinventing Python notebooks as reactive, reproducible, interactive, and Git-friendly environments for data workflows and AI prototyping. He helps build the core marimo notebook platform, pushing its reactive execution model, UI interactivity, and integration with modern development and AI tooling so that notebooks behave like dependable, shareable programs and apps rather than error-prone scratchpads.Join the Community: https://go.mlops.community/YTJoinInGet the newsletter: https://go.mlops.community/YTNewsletterMLOps GPU Guide: https://go.mlops.community/gpuguide// AbstractVincent Warmerdam joins Demetrios fresh off marimo's acquisition by Weights & Biases—and makes a bold claim: notebooks as we know them are outdated.They talk Molab (GPU-backed, cloud-hosted notebooks), LLMs that don't just chat but actually fix your SQL and debug your code, and why most data folks are consuming tools instead of experimenting. Vincent argues we should stop treating notebooks like static scratchpads and start treating them like dynamic apps powered by AI.It's a conversation about rethinking workflows, reclaiming creativity, and not outsourcing your brain to the model.// BioVincent is a senior data professional who worked as an engineer, researcher, team lead, and educator in the past. You might know him from tech talks with an attempt to defend common sense over hype in the data space. He is especially interested in understanding algorithmic systems so that one may prevent failure. As such, he has always had a preference to keep calm and check the dataset before flowing tonnes of tensors. He currently works at marimo, where he spends his time rethinking everything related to Python notebooks.// Related LinksWebsite: https://marimo.io/Coding Agent Conference: https://luma.com/codingagentsHyperbolic GPU Cloud: app.hyperbolic.ai~~~~~~~~ ✌️Connect With Us ✌️ ~~~~~~~Catch all episodes, blogs, newsletters, and more: https://go.mlops.community/TYExploreJoin our Slack community [https://go.mlops.community/slack]Follow us on X/Twitter [@mlopscommunity](https://x.com/mlopscommunity) or [LinkedIn](https://go.mlops.community/linkedin)] Sign up for the next meetup: [https://go.mlops.community/register]MLOps Swag/Merch: [https://shop.mlops.community/]MLOps GPU Guide: https://go.mlops.community/gpuguideConnect with Demetrios on LinkedIn: /dpbrinkmConnect with Vincent on LinkedIn: /vincentwarmerdam/Timestamps:[00:00] Context in Notebooks[00:24] Acquisition and Team Continuity[04:43] Coding Agent Conference Announcement![05:56] Hyperbolic GPU Cloud Ad[06:54] marimo and W&B Synergies[09:31] marimo Cloud Code Support[12:59] Hardest Code to Generate[16:22] Trough of Disillusionment[20:38] Agent Interaction in Notebooks[25:41] Wrap up

Subscribe to DTC Newsletter - ⁠https://dtcnews.link/signup⁠Amazon Marketing Cloud (AMC) used to feel “enterprise-only.” Not anymore. Tyler Masur (Head of Amazon at Pilothouse) breaks down what AMC actually does, how to use the no-code templates without being a SQL wizard, and the audience overlays that make broad keywords finally make sense. Role-based hook: For Amazon operators and DTC teams spending real money on Sponsored Ads who want lower ACOS without sacrificing scale.In this episode, we get tactical on:What AMC is (and isn't): audience building + deeper measurement layered on top of your existing console How to start with the no-code audience + analytics templates (and when AI-generated SQL helps) Why you should test AMC audiences in net-new campaigns (so you don't accidentally choke your winners)The “broad keyword + qualified audience” play (example: bidding on “cooler” but only for outdoors browsers)Measuring DSP impact: what happens after someone sees DSP, then hits Sponsored Brands/Products Who this is for: Amazon managers, DTC founders, and growth teams trying to scale Sponsored Ads past the “set it and forget it” phase.What to steal:Build a “generic keyword” campaign, then overlay an in-market audience (nodes/categories) so you can bid higher without paying for junk clicks.Keep audience tests isolated in new campaigns; don't jam audiences into legacy structures and hope.Run the AMC overlap reporting to spot the campaigns that actually increase conversion when paired together (then fund those).Timestamps:0:00 Amazon Marketing Cloud is now open to all sellers2:05 What AMC actually does: audiences and analytics4:10 No-code templates vs custom SQL queries (and the built-in AI helper)6:10 Audience targeting strategy to improve ACoS without over-narrowing8:55 Using prebuilt analytics to see which campaigns lift conversion together11:10 When AMC becomes worth it based on ad spend and effort required13:15 How Pilothouse uses AI day-to-day for Amazon work (including Rufus content)15:20 Measuring DSP incrementality and overlap with sponsored ads using AMC reports17:30 Platform notes: Amazon layoffs and the OpenAI + Amazon speculationSubscribe to DTC Newsletter - https://dtcnews.link/signupAdvertise on DTC - https://dtcnews.link/advertiseWork with Pilothouse - https://www.pilothouse.co/?utm_source=AKNF585Follow us on Instagram & Twitter - @dtcnewsletterWatch this interview on YouTube - https://dtcnews.link/video

This is episode 317 recorded on January 21st, 2026, where John & Jason talk about news that came out in January 2026 for Power BI & Microsoft Fabric in the Microsoft 365 Admin Center and some interesting articles on the Fabric Blog. For show notes please visit www.bifocal.show

In this episode of the Crazy Wisdom Podcast, host Stewart Alsop sits down with Larry Swanson, a knowledge architect, community builder, and host of the Knowledge Graph Insights podcast. They explore the relationship between knowledge graphs and ontologies, why these technologies matter in the age of AI, and how symbolic AI complements the current wave of large language models. The conversation traces the history of neuro-symbolic AI from its origins at Dartmouth in 1956 through the semantic web vision of Tim Berners-Lee, examining why knowledge architecture remains underappreciated despite being deployed at major enterprises like Netflix, Amazon, and LinkedIn. Swanson explains how RDF (Resource Description Framework) enables both machines and humans to work with structured knowledge in ways that relational databases can't, while Alsop shares his journey from knowledge management director to understanding the practical necessity of ontologies for business operations. They discuss the philosophical roots of the field, the separation between knowledge management practitioners and knowledge engineers, and why startups often overlook these approaches until scale demands them. You can find Larry's podcast at KGI.fm or search for Knowledge Graph Insights on Spotify and YouTube.Timestamps00:00 Introduction to Knowledge Graphs and Ontologies01:09 The Importance of Ontologies in AI04:14 Philosophy's Role in Knowledge Management10:20 Debating the Relevance of RDF15:41 The Distinction Between Knowledge Management and Knowledge Engineering21:07 The Human Element in AI and Knowledge Architecture25:07 Startups vs. Enterprises: The Knowledge Gap29:57 Deterministic vs. Probabilistic AI32:18 The Marketing of AI: A Historical Perspective33:57 The Role of Knowledge Architecture in AI39:00 Understanding RDF and Its Importance44:47 The Intersection of AI and Human Intelligence50:50 Future Visions: AI, Ontologies, and Human BehaviorKey Insights1. Knowledge Graphs Combine Structure and Instances Through Ontological Design. A knowledge graph is built using an ontology that describes a specific domain you want to understand or work with. It includes both an ontological description of the terrain—defining what things exist and how they relate to one another—and instances of those things mapped to real-world data. This combination of abstract structure and concrete examples is what makes knowledge graphs powerful for discovery, question-answering, and enabling agentic AI systems. Not everyone agrees on the precise definition, but this understanding represents the practical approach most knowledge architects use when building these systems.2. Ontology Engineering Has Deep Philosophical Roots That Inform Modern Practice. The field draws heavily from classical philosophy, particularly ontology (the nature of what you know), epistemology (how you know what you know), and logic. These thousands-year-old philosophical frameworks provide the rigorous foundation for modern knowledge representation. Living in Heidelberg surrounded by philosophers, Swanson has discovered how much of knowledge graph work connects upstream to these philosophical roots. This philosophical grounding becomes especially important during times when institutional structures are collapsing, as we need to create new epistemological frameworks for civilization—knowledge management and ontology become critical tools for restructuring how we understand and organize information.3. The Semantic Web Vision Aimed to Transform the Internet Into a Distributed Database. Twenty-five years ago, Tim Berners-Lee, Jim Hendler, and Ora Lassila published a landmark article in Scientific American proposing the semantic web. While Berners-Lee had already connected documents across the web through HTML and HTTP, the semantic web aimed to connect all the data—essentially turning the internet into a giant database. This vision led to the development of RDF (Resource Description Framework), which emerged from DARPA research and provides the technical foundation for building knowledge graphs and ontologies. The origin story involved solving simple but important problems, like disambiguating whether "Cook" referred to a verb, noun, or a person's name at an academic conference.4. Symbolic AI and Neural Networks Represent Complementary Approaches Like Fast and Slow Thinking. Drawing on Kahneman's "thinking fast and slow" framework, LLMs represent the "fast brain"—learning monsters that can process enormous amounts of information and recognize patterns through natural language interfaces. Symbolic AI and knowledge graphs represent the "slow brain"—capturing actual knowledge and facts that can counter hallucinations and provide deterministic, explainable reasoning. This complementarity is driving the re-emergence of neuro-symbolic AI, which combines both approaches. The fundamental distinction is that symbolic AI systems are deterministic and can be fully explained, while LLMs are probabilistic and stochastic, making them unsuitable for applications requiring absolute reliability, such as industrial robotics or pharmaceutical research.5. Knowledge Architecture Remains Underappreciated Despite Powering Major Enterprises. While machine learning engineers currently receive most of the attention and budget, knowledge graphs actually power systems at Netflix (the economic graph), Amazon (the product graph), LinkedIn, Meta, and most major enterprises. The technology has been described as "the most astoundingly successful failure in the history of technology"—the semantic web vision seemed to fail, yet more than half of web pages now contain RDF-formatted semantic markup through schema.org, and every major enterprise uses knowledge graph technology in the background. Knowledge architects remain underappreciated partly because the work is cognitively difficult, requires talking to people (which engineers often avoid), and most advanced practitioners have PhDs in computer science, logic, or philosophy.6. RDF's Simple Subject-Predicate-Object Structure Enables Meaning and Data Linking. Unlike relational databases that store data in tables with rows and columns, RDF uses the simplest linguistic structure: subject-predicate-object (like "Larry knows Stuart"). Each element has a unique URI identifier, which permits precise meaning and enables linked data across systems. This graph structure makes it much easier to connect data after the fact compared to navigating tabular structures in relational databases. On top of RDF sits an entire stack of technologies including schema languages, query languages, ontological languages, and constraints languages—everything needed to turn data into actionable knowledge. The goal is inferring or articulating knowledge from RDF-structured data.7. The Future Requires Decoupled Modular Architectures Combining Multiple AI Approaches. The vision for the future involves separation of concerns through microservices-like architectures where different systems handle what they do best. LLMs excel at discovering possibilities and generating lists, while knowledge graphs excel at articulating human-vetted, deterministic versions of that information that systems can reliably use. Every one of Swanson's 300 podcast interviews over ten years ultimately concludes that regardless of technology, success comes down to human beings, their behavior, and the cultural changes needed to implement systems. The assumption that we can simply eliminate people from processes misses that huma...

Ghousia Sultana is a data analyst with a strong foundation in data analytics, engineering, and business intelligence. She began her career as an HR Process Analyst, later transitioned into IT, and now works as a Data Analyst, leveraging tools like Python, SQL, Power BI, Azure, and Databricks to build scalable data pipelines and drive insights. She holds a Master's in Business Analytics and brings a deep interest in the intersection of AI and data. Currently, she is conducting research and writing on how data infrastructure, analytics, and machine learning come together to enable real-world AI solutions. Her work reflects a blend of hands-on technical expertise and a forward-looking perspective on the future of intelligent systems. 

Focus sur l’IA et son impact, écrans Samsung, projet Neom. Discussions sur Action Mesh, Omnitransfer, et Prism d’OpenAI. Quelques mots sur Intel Panther Lake et les écrans de Samsung.  Me soutenir sur Patreon Me retrouver sur YouTube On discute ensemble sur Discord Modèles IA de la semaine ActionMesh, Omnitransfer, et vidéos qui s’auto raffinent. Engram, du SQL dans ton LLM. ConceptMoe et raisonnements visuels. Maitres linéaires : les IA ont des valeurs très malléables. Principe Anthropic : qui enfume qui ? Anthropic et crock des parts de marchés… OpenAI lance Prism ! On va en voir de toutes les couleurs… Twentieth Century boy : Ami arrive à Paris. Config de canard : DuckDuck go avec ou sans IA ? Pas de Braga pas de chocolat Microsoft à fond dans l'IA ? Maia pas de problème ! Samsung, meilleure société écran ? Panthère vs gorgone : fight ! A Starlink to the past : qui paye la facture déjà ? Les fuites, ça pose toujours problème Neom mais sans cerveau, MBS suit la mode. Beyond meat… effectivement très au-delà de la viande. Participants Une émission préparée par Guillaume Poggiaspalla Présenté par Guillaume Vendé

Maintaining software over time rarely fails because of one bad decision. It fails because teams stop getting clear signals… and start guessing.In this episode, Robby talks with Lucas Roesler, Managing Partner and CTO at Contiamo. Lucas joins from Berlin to unpack what maintainability looks like in practice when you are dealing with real constraints… limited context, missing documentation, and systems that resist understanding.A big through-line is feedback. Lucas argues that long-lived systems become easier to change when they provide fast, trustworthy signals about what they are doing. That can look like tests that validate assumptions, tooling that makes runtime behavior visible, and a habit of designing for observability instead of treating it as a bolt-on.The conversation also gets concrete. Lucas shares a modernization effort built on a decade-old tangle of database logic… views, triggers, stored procedures, and materializations… created by a single engineer who was no longer around. With little documentation to lean on, the team had to build their own approach to “reading” the system and mapping dependencies before they could safely change anything.If you maintain software that has outlived its original authors, this is a grounded look at what helps teams move from uncertainty to confidence… without heroics, and without rewriting for sport.Episode Highlights[00:00:46] What well-maintained software has in common: Robby asks Lucas what traits show up in systems that hold together over time.[00:03:25] Readability at runtime: Lucas connects maintainability to observability and understanding what a system actually did.[00:16:08] Writing the system down as code: Infrastructure, CI/CD, and processes as code to reduce guesswork and improve reproducibility.[00:17:42] How client engagements work in practice: How Lucas' team collaborates with internal engineering teams and hands work off.[00:25:21] The “rat's nest” modernization story: Untangling a legacy data system with years of database logic and missing context.[00:29:40] Making data work testable: Why testability matters even when the “code” is SQL and pipelines.[00:34:59] Pivot back to feedback loops: Robby steers into why logs, metrics, and tracing shape better decision-making.[00:35:20] Why teams avoid metrics and tracing: The organizational friction of adding “one more component.”[00:42:59] Local observability with Grafana: Using visual feedback to spot waterfalls, sequential work, and hidden coupling.[00:50:00] Non-technical book recommendations: What Lucas reads and recommends outside of software.Links & ReferencesGuest and CompanyLucas Roesler: https://lucasroesler.com/Contiamo: https://contiamo.com/SocialMastodon: https://floss.social/@theaxerBluesky: https://bsky.app/profile/theaxer.bsky.socialBooks MentionedThe Wheel of Time (Robert Jordan): https://en.wikipedia.org/wiki/The_Wheel_of_TimeAccelerando (Charles Stross): https://en.wikipedia.org/wiki/AccelerandoCharles Stross: https://en.wikipedia.org/wiki/Charles_StrossThanks to Our Sponsor!Turn hours of debugging into just minutes! AppSignal is a performance monitoring and error-tracking tool designed for Ruby, Elixir, Python, Node.js, Javascript, and other frameworks.It offers six powerful features with one simple interface, providing developers with real-time insights into the performance and health of web applications.Keep your coding cool and error-free, one line at a time! Use the code maintainable to get a 10% discount for your first year. Check them out! Subscribe to Maintainable on:Apple PodcastsSpotifyOr search "Maintainable" wherever you stream your podcasts.Keep up to date with the Maintainable Podcast by joining the newsletter.

Help us become the #1 Data Podcast by leaving a rating & review! We are 67 reviews away! I spent a lot of time learning SQL the hard way. Knowing a few key ideas sooner would have changed everything.

This is episode 316 recorded on December 19th, 2025, where John & Jason talk about their predictions about 2024 & how they aged into 2025 and make their predictions for 2026 for Power BI & Microsoft Fabric. For show notes please visit www.bifocal.show

In this episode of the Women in Data Podcast, hosts Cecilia Oliveira and Karen Jean-Francois pull back the curtain on the "dirty little secret" of the data world: exactly how they are using AI to change the way they work. Moving past the headlines and the hype, Cecilia and Karen share a vulnerable look at their initial skepticism and how they shifted toward an "Augmentation Mindset." They dive into the practicalities of using AI as a junior collaborator—from cleaning messy data and writing SQL to the "meta" moment of using AI to help structure this very podcast episode. Whether you're feeling "productivity guilt" or pure curiosity, this episode is a guide to making AI work for you, so you can focus on the work only you can do.

Dive into the evolving modern data stack through the lens of observability, security, and log analytics as host Eric Kavanagh interviews Eric Tschetter of Imply and Mark Madsen of Third Nature about why vertically integrated observability platforms are giving way to more decoupled, composable architectures. Unpack how logs differ from traditional BI data, why schema-on-read changed the game, and how multiple query languages (SPL, KQL, SQL, and more) shape real-world workflows. Learn more about the cost and complexity trade-offs of data lakes, cloud storage, and retrieval at scale in this episode of DM Radio. 

If you're still guessing how marketing is really performing, this episode will flip the switch. Spencer breaks down why Sales Qualified Leads (SQLs) are the most important metric you can track and the best leading indicator of future revenue. You'll learn how to clearly define an SQL, why it matters more than raw lead volume, and how tight communication between sales and marketing turns SQLs into better forecasting, smarter ad spend, and higher close rates. If you want fewer “junk leads” and more projects that actually fit your business, this is a must-listen.

In this episode of the Crazy Wisdom podcast, host Stewart Alsop welcomes Roni Burd, a data and AI executive with extensive experience at Amazon and Microsoft, for a deep dive into the evolving landscape of data management and artificial intelligence in enterprise environments. Their conversation explores the longstanding challenges organizations face with knowledge management and data architecture, from the traditional bronze-silver-gold data processing pipeline to how AI agents are revolutionizing how people interact with organizational data without needing SQL or Python expertise. Burd shares insights on the economics of AI implementation at scale, the debate between one-size-fits-all models versus specialized fine-tuned solutions, and the technical constraints that prevent companies like Apple from upgrading services like Siri to modern LLM capabilities, while discussing the future of inference optimization and the hundreds-of-millions-of-dollars cost barrier that makes architectural experimentation in AI uniquely expensive compared to other industries.Timestamps00:00 Introduction to Data and AI Challenges03:08 The Evolution of Data Management05:54 Understanding Data Quality and Metadata08:57 The Role of AI in Data Cleaning11:50 Knowledge Management in Large Organizations14:55 The Future of AI and LLMs17:59 Economics of AI Implementation29:14 The Importance of LLMs for Major Tech Companies32:00 Open Source: Opportunities and Challenges35:19 The Future of AI Inference and Hardware43:24 Optimizing Inference: The Next Frontier49:23 The Commercial Viability of AI ModelsKey Insights1. Data Architecture Evolution: The industry has evolved through bronze-silver-gold data layers, where bronze is raw data, silver is cleaned/processed data, and gold is business-ready datasets. However, this creates bottlenecks as stakeholders lose access to original data during the cleaning process, making metadata and data cataloging increasingly critical for organizations.2. AI Democratizing Data Access: LLMs are breaking down technical barriers by allowing business users to query data in plain English without needing SQL, Python, or dashboarding skills. This represents a fundamental shift from requiring intermediaries to direct stakeholder access, though the full implications remain speculative.3. Economics Drive AI Architecture Decisions: Token costs and latency requirements are major factors determining AI implementation. Companies like Meta likely need their own models because paying per-token for billions of social media interactions would be economically unfeasible, driving the need for self-hosted solutions.4. One Model Won't Rule Them All: Despite initial hopes for universal models, the reality points toward specialized models for different use cases. This is driven by economics (smaller models for simple tasks), performance requirements (millisecond response times), and industry-specific needs (medical, military terminology).5. Inference is the Commercial Battleground: The majority of commercial AI value lies in inference rather than training. Current GPUs, while specialized for graphics and matrix operations, may still be too general for optimal inference performance, creating opportunities for even more specialized hardware.6. Open Source vs Open Weights Distinction: True open source in AI means access to architecture for debugging and modification, while "open weights" enables fine-tuning and customization. This distinction is crucial for enterprise adoption, as open weights provide the flexibility companies need without starting from scratch.7. Architecture Innovation Faces Expensive Testing Loops: Unlike database optimization where query plans can be easily modified, testing new AI architectures requires expensive retraining cycles costing hundreds of millions of dollars. This creates a potential innovation bottleneck, similar to aerospace industries where testing new designs is prohibitively expensive.

Nik and Michael are joined by Lev Kokotov for an update on all things PgDog. Here are some links to things they mentioned:Lev Kokotov https://postgres.fm/people/lev-kokotovPgDog https://github.com/pgdogdev/pgdogOur first PgDog episode (March 2025) https://postgres.fm/episodes/pgdogSharding pgvector (blog post by Lev) https://pgdog.dev/blog/sharding-pgvectorPrepared statements and partitioned table lock explosion (series by Nik) https://postgres.ai/blog/20251028-postgres-marathon-2-009~~~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 credit to:Jessie Draws for the elephant artwork

In this episode, Chris, Andrew, and David dive into details about refactoring with SQL, updates on new Ruby versions, and share their views on various developer tools including Mise, Overmind, and Foreman. They also touch on standardizing tools within their teams, the benefits of using Mise for Postgres, and the efficiency of task scripts. The conversation also covers encoding issues, Basecamp Fizzy SSFR protection, and rich-text editors like Lexxy and its application in Basecamp. Additionally, there's a light-hearted discussion on the speculative future of AI and Neuralink.  Hit download now to hear more! LinksJudoscale- Remote Ruby listener giftRuby ReleasesForeman-GitHubOvermind-GitHubMise versionsUsage SpecificationA Ruby YAML parser (blog post by Kevin Newton)Lexxy-GitHubBasecamp Fizzy SSRF protection-GitHubNeuralinkAndrew Mason-The MatrixHoneybadgerHoneybadger is an application health monitoring tool built by developers for developers.JudoscaleMake your deployments bulletproof with autoscaling that just works.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you. Chris Oliver X/Twitter Andrew Mason X/Twitter Jason Charnes X/Twitter

Nik and Michael are joined by Radim Marek from boringSQL to talk about RegreSQL, a regression testing tool for SQL queries they forked and improved recently. Here are some links to things they mentioned:Radim Marek https://postgres.fm/people/radim-marekboringSQL https://boringsql.comRegreSQL: Regression Testing for PostgreSQL Queries (blog post by Radim) https://boringsql.com/posts/regresql-testing-queriesDiscussion on Hacker News https://news.ycombinator.com/item?id=45924619 Radim's fork of RegreSQL on GitHub https://github.com/boringSQL/regresql Original RegreSQL on GitHub (by Dimitri Fontaine) https://github.com/dimitri/regresql The Art of PostgreSQL (book) https://theartofpostgresql.comHow to make the non-production Postgres planner behave like in production (how-to post by Nik) https://postgres.ai/docs/postgres-howtos/performance-optimization/query-tuning/how-to-imitate-production-planner Just because you're getting an index scan, doesn't mean you can't do better! (Blog post by Michael) https://www.pgmustard.com/blog/index-scan-doesnt-mean-its-fastboringSQL Labs https://labs.boringsql.com~~~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 credit to:Jessie Draws for the elephant artwork

What happens when engineering teams can finally see the business impact of every technical decision they make? In this episode of Tech Talks Daily, I sat down with Chris Cooney, Director of Advocacy at Coralogix, to unpack why observability is no longer just an engineering concern, but a strategic lever for the entire business. Chris joined me fresh from AWS re:Invent, where he had been challenging a long-standing assumption that technical signals like CPU usage, error rates, and logs belong only in engineering silos. Instead, he argues that these signals, when enriched and interpreted correctly, can tell a much more powerful story about revenue loss, customer experience, and competitive advantage. We explored Coralogix's Observability Maturity Model, a four-stage framework that takes organizations from basic telemetry collection through to business-level decision making. Chris shared how many teams stall at measuring engineering health, without ever connecting that data to customer impact or financial outcomes. The conversation became especially tangible when he explained how a single failed checkout log can be enriched with product and pricing data to reveal a bug costing thousands of dollars per day. That shift, from "fix this tech debt" to "fix this issue draining revenue," fundamentally changes how priorities are set across teams. Chris also introduced Oli, Coralogix's AI observability agent, and explained why it is designed as an agent rather than a simple assistant. We talked about how Oli can autonomously investigate issues across logs, metrics, traces, alerts, and dashboards, allowing anyone in the organization to ask questions in plain English and receive actionable insights. From diagnosing a complex SQL injection attempt to surfacing downstream customer impact, Oli represents a move toward democratizing observability data far beyond engineering teams. Throughout our discussion, a clear theme emerged. When technical health is directly tied to business health, observability stops being seen as a cost center and starts becoming a competitive advantage. By giving autonomous engineering teams visibility into real-world impact, organizations can make faster, better decisions, foster innovation, and avoid the blind spots that have cost even well-known brands millions. So if observability still feels like a necessary expense rather than a growth driver in your organization, what would change if every technical signal could be translated into clear business impact, and who would make better decisions if they could finally see that connection? Useful LInks Connect with Chris Cooney Learn more about Coralogix Follow on LinkedIn Thanks to our sponsors, Alcor, for supporting the show.

SHOW: 992SHOW TRANSCRIPT: The Cloudcast #992 TranscriptSHOW VIDEO: https://youtube.com/@TheCloudcastNET NEW TO CLOUD? CHECK OUT OUR OTHER PODCAST - "CLOUDCAST BASICS" SHOW NOTES:Tonic.ai websiteTonic Validate Product PageTonic Validate GitHubTopic 1 - Adam, welcome to the show. Give everyone a brief introduction.Topic 2: Our topic today is RAG systems, specifically RAG in production. Let's start with customization sources and types. When it comes to customizing off-the-shelf LLMs, RAG is one option, as is an MCP connection to a SQL database, and there is pre- and post-training, as well as fine-tuning. How does an organization decide what path is best for customization?Topic 3 - RAG came on the scene as the savior for organizations that want to use customer AI without the need for fine-tuning and additional training. It has either gone through or is currently still in the trough of disillusionment. What are your thoughts on RAG's evolution and the challenges it faces?Topic 4 - Let's walk through the basics of validation. Once you set up RAG, how would an organization know it works? How is accuracy measured and validated? Are you looking for hallucinations? Context quality?Topic 5 - What is Tonic Validate, and where does it fit into this stack? Is it in band? Out of band? Built into the CI workflow?Topic 6 - Accuracy is one aspect, but we hear more and more about ROI for Enterprises. How should ROI, risk, and compliance be measured?Topic 7 - Where and how does security fit into all of this? Also, your thoughts on synthetic data for training vs. real data?Topic 8 - If anyone is interested, what's the best way to get started?FEEDBACK?Email: show at the cloudcast dot netBluesky: @cloudcastpod.bsky.socialTwitter/X: @cloudcastpodInstagram: @cloudcastpodTikTok: @cloudcastpod

The FBI warns of Kimsuky quishing. Singapore warns of a critical vulnerability in Advantech IoT management platforms. Russia's Fancy Bear targets energy research, defense collaboration, and government communications. Malaysia and Indonesia suspend access to X. Researchers warn a large-scale fraud operation is using AI-generated personas to trap mobile users in a social engineering scam. BreachForums gets breached. The NSA names a new Deputy Director. Monday Biz Brief. Our guest is Sasha Ingber, host of the International Spy Museum's SpyCast podcast. The commuter who hacked his scooter.  Remember to leave us a 5-star rating and review in your favorite podcast app. Miss an episode? Sign-up for our daily intelligence roundup, Daily Briefing, and you'll never miss a beat. And be sure to follow CyberWire Daily on LinkedIn. CyberWire Guest Today we are joined by Sasha Ingber, host of the International Spy Museum's SpyCast podcast, on the return of SpyCast to the N2K CyberWire network. Selected Reading North Korea–linked APT Kimsuky behind quishing attacks, FBI warns (Security Affairs)  Advantech patches maximum-severity SQL injection flaw in IoT products (Beyond Machines) Russia's APT28 Targeting Energy Research, Defense Collaboration Entities (SecurityWeek) Malaysia and Indonesia block X over deepfake smut (The Register) New OPCOPRO Scam Uses AI and Fake WhatsApp Groups to Defraud Victim (Hackread) BreachForums hacking forum database leaked, exposing 324,000 accounts (Bleeping Computer) Former NSA insider Kosiba brought back as spy agency's No. 2 (The Record) Vega raises $120 million in a Series B round led by Accel. Reverse engineering my cloud-connected e-scooter and finding the master key to unlock all scooters (Rasmus Moorats) Share your feedback. What do you think about CyberWire Daily? Please take a few minutes to share your thoughts with us by completing our brief listener survey. Thank you for helping us continue to improve our show. Want to hear your company in the show? N2K CyberWire helps you reach the industry's most influential leaders and operators, while building visibility, authority, and connectivity across the cybersecurity community. Learn more at sponsor.thecyberwire.com. The CyberWire is a production of N2K Networks, your source for strategic workforce intelligence. © N2K Networks, Inc. Learn more about your ad choices. Visit megaphone.fm/adchoices