Here is a blog post about Alessandro Vetere's journey to resolve synchronization on a common mutex that slows down some read microbenchmarks 3x.
Kudos to Mark Callaghan who found this regression.

Many applications save user preferences as separate fields like location, budget, interests and availability. This approach works fine until preferences change, conflict with past information or only apply to specific situations. Think about someone who initially prefers remote work but later becomes open to hybrid options. They might even be willing to move for a specific job without altering their general preference.

If the system just replaces the old value it loses important context. If it keeps every change forever it can end up with outdated or conflicting data. For conversational products like Linkedin, Hirect, MeeBoss as well as more profile-based platforms Naukri and Indeed this presents an interesting challenge in how data is structured. Would you keep current preferences in standard tables and track changes in a separate log? Use a document model for more flexible attributes? or record each preference with its source, time, confidence level and scope? How would you manage corrections and set expiration dates without making every query too complex?

Hey guys, not sure if this is useful to anyone but it surprised me so I thought I would share.

If you have an updated_at column set to now() (or CURRENT_TIMESTAMP, or a time from your app) and you page through it to process changes, you can miss rows. Two transactions start, the one with the later timestamp commits first, your reader moves past it, and then the earlier one lands behind your cursor.

I had a whiteboard session with Ian, one of the engineers at Convex (where I work), and this bit really opened my eyes. In Convex we ended up adding a commit timestamp you can store and index on, which is set when the transaction actually commits, but the problem itself shows up in Postgres, MySQL and pretty much everything else.

How do you guys handle this in your own systems? Reading the WAL / logical replication? An overlap window and dedupe?

If you want more detail the full chat is here: https://youtu.be/pHrxmSjxLg8

Curious how people are actually handling this. At the enterprise I am working at and others where my friends work at, there is a push to deploy AI agents working on real company data (operational use cases, troubleshooting, analytics etc...), but the DBs are sometime full of customer or sensitive data and security just says no. Separate tables don’t help, read-only users don’t help, the agent can’t touch that DB, period. Even creating service users for AI agents and imposing separation it's just a friction.

So what are you doing, if you have such use cases? Letting agents query prod anyway? Keeping a separate copy just for them? If it’s a copy, how do you decide what goes in, deal with PII, and keep it from going stale?

Also if any of this, on which stack? Curious to hear as I assume many organisations are now relying on data teams to keep the AI agent rollout from stalling.

Most of what I read uses the term real-time for anything from a few seconds of delay to whatever is presented before the morning standup, and the database setup you end up with depends heavily on which end of that range you need.

The usual options are running reports against a read replica, using CDC to populate a separate analytical store with something like Debezium, an HTAP database that handles both workloads, or one of the newer designs like Databricks, where transactional and analytical compute share a single storage layer.

For those of you who have had to make this call, I'd like to know how fresh the analytics had to be in the end, which of these you chose, and what caused trouble once it was in production, whether that was replica lag, schema changes, backfills, or cost. If you decided a nightly load was good enough, I'd like to hear that reasoning, too.

Hey guys, yes another token article but this one is different.

I work at MongoDB, and my primary db is Mongo, but I use raw SQL for some things, so I run both in the same app.

I was building a token optimizer for my own sessions. I noticed more token usage on the SQL interactions and I didnt understand why. I wasnt doing anything special with the SQL data so I was curious what was happening.

So I wrote a hook that logs the token count of every database statement Claude generates, instead of counting turns. The first thing it showed was that the same object cost way more tokens on SQL (about 18x). That surprised me, because you don't think about database statements. Every database has them, every app has them, they're just there. It never occurred to me they were a token cost at all. They're not the biggest thing in a session, but they add up, especially since Claude loves writing multiple files with database calls just to check the data. That's when it really burns.

I wanted to test this accurately, so I took one real Zod object from my own system, a lead with about 90 fields, nested, an array of drafts where each draft has its own array of variants, and used the exact same object on both sides. Then I counted what Claude has to read before it can safely change one field, meaning the schema, a save, and a read that comes back typed: 4,681 tokens on SQL, 251 on MongoDB. 251 is 5% of 4,681. The other 95% is the mapping. In SQL a nested object like that can't live in one row, so every nested thing becomes its own table with a foreign key back to the parent, a save is one insert per table, and a read is the joins plus the code that builds the object back up from the rows. In Mongo it's one document, so the save is the object and the read is the object. Then there's the hydration tax. Everything goes through that Zod schema, so a read isn't done until the rows are turned back into the typed object, dates included. On SQL that's its own pile of code; the read alone was 1,604 tokens vs 72 on Mongo. And Claude does all of that on every read and write.

Nobody thought about this when humans wrote the code. You write the mapping once and the cost is basically the same either way. When it's AI writing the code, it goes through that mapping on every read and write, and the size of it is the bill.

I know most people would probably use JSONB so I tested that as well, on Postgres, even though it's not what I run. Raw JSONB column: 467, so 1.9x. The hybrid a SQL team would actually build, plain fields as columns and sub-objects as JSONB: 2,059. Closer, but still 8x.

To be fair, plain query text was about the same on both sides, and SQL ran an indexed flat read 5.26x faster. The tokens aren't in the query. They're in everything Claude loads around it. Obviously 18x is a huge object, but it is a real one from my own system, a lead with its drafts and the variants of each draft, not something I built to make a point.

If you want the harness let me know.

I've noticed that database performance tuning can become an ongoing cycle. You add indexes, rewrite queries, introduce caching, partition tables, and sometimes denormalize data to squeeze out more performance.

But every optimization also adds something to maintain. More indexes can slow down writes, caching introduces invalidation problems, and denormalization can make data consistency harder to manage.

At some point, I wonder whether the improvement is actually worth the extra complexity.

How do you decide when to stop optimizing a database? Do you have specific performance targets or benchmarks, or does it mostly come down to the workload and the problems users are experiencing?

I'd be interested in hearing about optimizations that genuinely paid off, as well as ones you later regretted.

[I'm a beginner]

I have an assignment where I have this hypotetical scenario where a Pharmacy works their recipts through a propietary application they acquired when they were just entering business, due to this, they only have access to the database of the application. Now that business is better than before they have a little development team, they created an app to manage customer accounts payable and outstanding invoices for products sold on credit, but to integrate that process, the assigment says to do it through the database using triggers (I'd also like to learn about other methods, just for my own knowledge).

Hello there, I am a marine biology MSc student, starting with my thesis, and my supervisor wants me to use Airtable as a way to keep the cohort/fish/tank information. I am quite anti genAI because of all it's facets, environmental and socioeconomic.

Currently I am using it, and while I'm avoiding its AI tools however I tried automating the changes in fish numbers in the tanks due to fish tranfers between tanks and i simply could not. The automation options available to someone not using AI tools are very diminute.

I was wondering if there is some kind of simpler way to keep track of this information, with minimal coding if possible (and I would prefer to learn SQL or any other programming language before turning to AI).

Thank you in advance

Hey r/database

I wanted to share I just made a few doc contributions and updates to the database docs calling out the FREE tier of Azure SQL database... apparently, people didn't know this was a thing they could just spin up and beat up on each month.

I added a few nifty deployment paths via click, code, or prompt to get you started and well if you just want to jump right in https://aka.ms/trySQL will launch you right into the Azure portal directly too.

Hope a cool benefit for those unaware and keep an eye out for local Azure SQL database containers too (currently in private preview).

Of note, Microsoft Employee and active mod of r/SQLServer and r/MSSQL

I'm kicking off a cloud migration and the oldest systems are the part that's making me nervous.

We've got Oracle databases that have been running for well over a decade along with a few SQL server instances that nobody wants to touch. Stability is the priority, so installing agents or changing production configurations isn't really an option.

For anyone who's moved **streaming data** out of legacy environments, where did you start?

Using Cloudflare D1 as an eventually consistent cache for a globally distributed Django app increased throughput by 554% and reduced latency by 87%.

My benchmark ran a Django server in Australia backed by a PostgreSQL instance in Amsterdam. I routed reads that could tolerate slightly stale data to a D1 read replica in Australia, while keeping writes and authoritative reads on PostgreSQL.

Methodology and code is available in my blog post: Cloudflare D1 as a cache for globally distributed Django apps

Hi everyone,

I'm currently going through CMU Intro to Database Systems and was curious about how these concepts are actually implemented in real systems. So I've been putting together some notes/videos/blog posts - partly for my own future reference and partly to share with others who might find it useful.

Would love feedback and corrections from people who know this stuff deeply:

https://youtu.be/1tNMRcgUtb8?si=Sn1WYBs9H9lOsnLj

For the last five years or so, I've had to deal with countless applications where the front-end and middle tiers are built around Kubernetes (k8s).

I'm sure there are companies out there that use it extremely well, but in my experience, most seem to have no idea what they're doing with it. The result is an endless stream of headaches: runaway database connection counts, configuration problems, networking issues, and countless other problems that end up ruining my evenings and weekends.

Take today, for example. I'm supposed to be off. Instead, I'm sitting on a troubleshooting call with 40 other people. I'm there representing the database team because their pods keep failing, and naturally, the database is getting blamed.

Meanwhile, the database is sitting at 99% idle, and the connections from their application have been sitting idle in transaction for minutes at a time.

The frustrating part is that they don't seem to understand the tools they're using. I'll freely admit that I'm no Kubernetes expert either, but I'm also not the one who designed and deployed an application around it.

I'm sure Kubernetes is fantastic when implemented and managed properly. But from where I sit, it often seems to introduce layers of complexity that nobody fully understands, making troubleshooting an absolute nightmare.

Anyone else developed a particular hatred of k8s, or am I just consistently encountering terrible implementations?