I feel that serving a single-page app with a catch-all fallback is fine for an app behind a login but costly for anything else you want found. Search engines will treat missing sitemap.xml/robots.txt or even llms.txt as soft 404s. Any tools that just check the status will think those files exist. So AI crawlers will either have to start using JS, this as they admit will hurt SEO, but more importantly today GEO.
This is nothing but an attempt to disenfranchise minorities and people living paycheck-to-paycheck that can afford the time to deal with yet another ID... this is an old technique, just like gerrymandering, poll intimidations, and the all the tactics republicans have been using for years.
Supabase is a great product, we use it for all of our products, but we also need OSS solutions that can be self-hosted. For Supabase, I hope the platform improves. SQLite has become the standard, we need that standard (other than the SQL93 part) to be created and maintained so that other can drop a paid for product and handle the server-side themselves is the choose to.
Agree. supabase is a great product for prototyping. Their free tier is really helpful. But the value of instant access to a real postgres db is also where inevitable pain comes from. A prototype is fun until it's not and I've never managed to maintain app-based side projects longer than a few months. Only static deployments survive.
Supabase was really early in the "throwaway full-stack environments" space. Very helpful but I find myself moving to edge networks with sqlite in spite of my dislike for javascript.
Isn't this what this sounds like? You self-host Turso at the start, and you can gracefully scale to managed Turso (cloud), then to managed Postgres (Supabase). And Turso has experimental support for a Postgres frontend (alongside the SQLite frontend).
^ this is exactly the plan. An appropriate stack for each part of your journey.
The blog post captures it really well:
> As agents build more software, we believe database demand will outpace the world’s current capacity to support them. So we need infrastructure that can scale to meet this growth and is suited to how we build with agents.
> Agents should be able to create a database as easily as creating a file, with just as little concern about cost. For smaller workloads, that shouldn’t require provisioning a dedicated machine every time. Databases should be cheap to create, available on demand, and have a clear path to production when needed.
> SQLite is well suited to these small, on-demand workloads. Postgres is what you want as your application scales. We want builders to have the same developer experience from prototyping to production.
anecdotally I think this applies more specifically for 0-1 side-projects. They can be serious attempts at startups, but they start small and with AI the feedback loop should be rapid and fierce. For this you want lightweight infrastructure that the agent can reason about and not create a mess. So an edge network with sqlite is pretty killer.
The current "slow down" is a back-handed attempt to let the world catch up with the amount of slop that has been generated. The speed and time-to-market bill is piling up and in the next 5 years there will no humans that can understand this mess. So agentic SWE systems, need to change. Either we trust the validation layer at the end, or we take back control and also learn along the way.
