film42

The postmaster is effectively your supervisor. It could see the child segfault and abort the whole DB, but that would be deferring supervision to your init system. Not ideal.

You are correct! TIL, and thank you. Connection processes get a SIGQUIT, shared buffers cleared, and WAL replayed, but postmaster stays alive. It's effectively an online restart.

A million users? Hell, I'd bet 99.999% of live postgres databases in existence serve less than 5 users on average. Even among products that actually make a profit, I bet 99.9% of them serve less than 100 customers a day. We hooligans on hacker news manage the 0.1% of databases, and in my newfound consulting life, I'm hoping to never support one of those again.

A thread per connection is a almost always the correct decision for performance, but by choosing a process per connection, postgres is able to let you load whatever sketchy extensions you want. Worst case you crash the process, not the database. It would be nice if you could strike a balance so a segfaul in the extension only crashes a small percentage of connections, not the whole thing.

I've seen companies put a percentage of the team on a PIP as a "this is not a layoff but we do need to cut costs" situation. Hopefully Elastic is just being honest about it?

I'm surprised they didn't do this the first time around. Like, a user says they forgot their password and you tell them they don't actually have an account, that's an information disclosure vulnerability. Not automatically falling back to Opus just lets the "attacker" know they are bumping against the guardrails and they need to try a different strategy.

It's Anthropic's product and they can do what they want, but my concern is what happens if Fable's product team decides that they can route 25% of traffic to Opus, bill it as Fable, and max their KPIs. That just doesn't sit right.

Acquisitions change priorities and layoffs put the squeeze on people. AI is for sure in the mix there, but open source decay is a result of no room in budgets for anything but maximizing revenue.

To be honest, I think it's just a more honest score of what Opus 4.6 actually was. Once contexts get sufficiently large, Opus develops pretty bad short term memory loss.

I hope it comes down to the NTSB recommending more controllers (or better conditions for controllers) to avoid task saturation, not just more process. It's incredible what a single controller is capable of doing, but for major areas like NYC, it's not enough.

Camera cuts to a tech bro at his desk with 3 jobs and 5 instances of Claude Code running:

I had [the Register] explain to me three times what [Kim] got arrested for because it sounds an awful lot like what I do here every day.

Maybe. When it comes to actual payments, fee structures don't allow for this outside of the laboratory.

Maybe so. OLED comes with a risk, but I've run mine at 70-75% brightness with no issues. I probably drive mine ~2,500 hours per year, so if we make it 4 years that is a huge win in my book for something I stare at all day long.

Plus, coding at night on OLED just makes me want to write more code. It's great.

I bought an LG 32" 4k OLED for $999 and it's hands down the best display I've ever used. No burn in even with lots of static browser/terminal windows for days and days. The fact that it's $3k and _not_ OLED is insulting.

Just 10 minutes ago I was working with a very large semi-malformed excel file generated by a mainframe. DuckDB was able to load it with all_varchar (just keep everything a string) in under a second.

I'm still waiting for Excel to load the file.

I made the switch on a new project and I don't regret it but it's still early days software despite the marketing. Concurrency control is fantastic, but it doesn't always work. I've woken up to see all threads occupied with a job that should be concurrency of 1.

I've also run into issues where a db connection pool is filled up and solid queue silently fails. No error or logs, just stops polling forever until manual restart. Far from ideal.

But, I can live with it. I am going for minimal maintenance, and the ability to run solid queue under puma inside rails on cloud run is just so easy. Having ~3 solid queue related issues a year is acceptable for my use case, but that doesn't mean it will be ok for others.

I spend a lot of time out of reception and starlink has been fantastic. So much so that I leave it on anytime I'm driving where I have cellular reception because it's just consistently good. I get ~100Mbps whether it's a forest service road, ATV trail, or on the highway through curvy mountain passes.

I'm on the 50GB plan so doubling for free is very nice, but it looks like they yanked the ability to optionally purchase additional high speed data for $1/GB. Maybe it's still there?

Same here. I was told it would take a at least year on the waitlist. A month later I had 2 friends offer me their spot. They weren't impressed with the truck after a few reviews came out showing bad towing performance. I opted to buy a used ICE truck instead and have zero regrets.

Is open router still sending all OCR jobs to Mistral? I wonder if they're trying to keep that spot. Seems like Mistral and Google are the best at OCR right now, with Google leading Mistral by a fair bit.

Installed _on_ an engine that operates at 200ºC!

This is why I migrated my apps that need an LLM to Gemini. No model degradation so far all through the v2.5 model generation. What is Anthropic doing? Swapping for a quantized version of the model?

At this point I'm only using google models via Vertex AI for my apps. They have a weird QoS rate limit but in general Gemini has been consistently top tier for everything I've thrown at it.

Anecdotal, but I've also not experienced any regression in Gemini quality where Claude/OpenAI might push iterative updates (or quantized variants for performance) that cause my test bench to fail more often.

It's a cash grab. More conversational AI means more folks running out of free or lower paid tier tokens faster, leading to more upsell opportunities. API users will pay more in output tokens by default.

Example, I asked Claude a high level question about p2p systems and it started writing code in 3 languages. Ignoring the code, asking a follow up about the fundamentals, it answered and then rewrote the code 3 times. After a few minutes I hit a token limit for the first time.

AKA... 70% of existing google cloud users have filled out a support ticket, which starts with a chat bot.

Maybe look at R2 or Wasabi instead of S3. That would cut your storage bill by 3x and take your cloud network bill to zero. IMO self-managing DBs always sucks no matter what you do.

Or you have PTSD after 10 years of being on-call 24/7 for your company's stack. I've built my next chapter around offloading the pager. Worth every penny.

They created their business on open source. Free software was their top of funnel. Free customers become paid customers, and fund the business. They are more than welcome to change this, but there is no way they don't end up with egg on their face, and that's what we're seeing here.

I have a feeling this is IBM dipping their toes into the water of Postgres after seeing Databricks acquire Neon and Snowflake acquire CrunchyData. Won't be surprised if IBM acquires them next year. It makes a lot of sense and I wish everyone the best of luck.

From the outset, CockroachDB has a "just scale it up" product, an open-source presence, a serverless product with pricing similar to DSQL from AWS, and enterprise support. There is a lot to work with there if you're IBM.

I'm a fan because it's something you can explicitly turn on and off. For my Docker based app, I really want to verify the completeness of imports. Preferably, at build and test time. In fact, most of the time I will likely disable lazy loading outright. But, I would really appreciate a faster loading CLI tool.

However, there is a pattern in python to raise an error if, say, pandas doesn't have an excel library installed, which is fine. In the future, will maintainers opt to include a bunch of unused libraries since they won't negatively impact startup time? (Think pandas including 3-4 excel parsers by default, since it will only be loaded when called). It's a much better UX, but, now if you opt out of lazy loading, your code will take longer to load than without it.

My guess is both will look about the same with real world workloads. Worker is certainly more predictable which is safer in general. That said, I appreciate the callout about signal throughput on workers (fewer connections farm to more processes vs each connection getting its own io_uring setup with upper bound being the throughput for a single process). Again, I doubt it makes any difference for 99.9999% of apps out there.

Very cool post. If Jeff Geerling is reading this, I wouldn't mind watching a video on each of these ;)