Also a fan and user of Timescale, and I hate the serverless phase.
I'm pretty sure everyone is pushing it so they can make money from SaS. But if this allows them to give it away for free, then I'm all for it ( just won't be using it ).
I'm pretty sure everyone is pushing it so they can make money from SaS. But if this allows them to give it away for free, then I'm all for it ( just won't be using it ).
I also used to hate the phrase. But now I get it. And it's not about marketing, but about the idea that the developers _doesn't shouldn't have to worry about the server_.
For example, when you run a DB on a classic DBaaS, you have to worry about CPU, memory, storage provisioning. But when you use a classic SaaS service (e.g., Stripe, Twilio), you don't think about servers at all - but rather just how much you are consuming.
The Serverless model for databases is aiming to apply a SaaS like experience but for DBaaS. Where you don't need to think about provisioning, but about consumption.
What we (try to) do in this article is to push beyond that serverless paradigm. We believe there are real drawbacks to the "serverless black box" architecture that the industry is building, and what (we believe) developers need (including ourselves) is a more a "transparent box."
Hope this helps. But "serverless" also feels a little like "horseless carriages". I suspect in 5 years we'll have a better term that describes this concept for what it _is_, not what it _isn't_.
From the blog post: "So today’s serverless data platforms are not familiar or flexible. But further, black boxes are never truly easy and worry free: you never know if there are any skeletons lurking in the proverbial closet, just waiting to cause your service to fall over."
(Timescale employee here)
Call it managed DB as a service and you're more honest in your product offering. You're suffering marketing-speak in lieu of honesty for a technical product - bad plan, imo.
Your target market will understand.
Ignore the HackerNews naysayers who are stuck in the past.
But for better or worse, it seems like the industry has adopted it.
So, we're trying to explain actually how our vision is different.
In that we don't want to hide developers completely from their services behind these black-box abstractions. But provide something that's similarly easy and scalable (and automated), but allow developers greater control, flexibility, and understanding when they want it.