But that's not what we are saying; we're suggesting use Postgres until you truly need something else. 90% of applications aren't "web scale", keep the stack simple and portable. There's no good reason to slap in a ton of moving parts until they are truly needed.
It started well, though. It was an analytics tool with a developer-oriented mind; it was refreshing compared to the competition. But all good things do seem to come to an end, especially when it is a company. They went full weirdos in the last 2 years. AI just made everything worse.
PostHog was wonderful as an analytics solution, with its developer-first approach, good tools, and nice pricing.
At this point, I lost count of how many times in the last two decades I fell for it, although I'm more used to it now. Companies that grow into success and change. With the AI frenzy, PostHog also started going all-in, and not only that, but they seem to be exploring no-coding tools and whatnot. Supabase is another one that was cool, but now it is in the AI abyss.
Indeed, at this point, I'm the constant. Maybe I'm the problem here, and perhaps I should learn to accept the new AI overlords, give up and go full AI.
> Supabase is another one that was cool, but now it is in the AI abyss.
(supabase ceo) I'm curious what gives you this impression? it's true that a lot of platforms build on top of Supabase, but our focus is still just building the best Postgres platform we can (OrioleDB, Multigres, etc)
admittedly we've also had to shift a lot of our tooling to things like Claude/Codex, but that's more reflective of how people are building now
This one has yet to enter my head. I read Martin Fowler's related article* a few times, and it is sound... But I still can't see microservices being so "complex" to be so avoided early on. Especially in 2026, with the level of IaC and pipelines we have. I might be naïve, but I just don't get it.
It depends on your workload etc - but there are TONs of advantages for the monolith approach when you factor in dev environments, access to good data for testing/development, dependencies on components/libraries/services etc.
Note: I'm saying microservices CAN be the right answer, just not always and we should over-engineering.
sauce: I work as a product engineer where we use microservices extensively. I have also worked on monoliths. Preferred working on the monoliths overall I think.
