LayerbaseLayerbase

QuestDB Cloud is gone. Here is what to use instead.

QuestDBTime-seriesDatabases

QuestDB Cloud is no longer accepting new signups. The AWS Marketplace listing is dead. The pricing page now sends you to the Enterprise contact form, which is the BYOC product (you bring an AWS or GCP account, they manage the deployment inside it). That works fine if you're a company with a procurement process, a cloud account, and a willingness to talk to sales. It does not work if you're one developer who wanted to spin up a QuestDB instance to test ingest rates over the weekend.

I started Layerbase Cloud partly because of moves like this. Engines I love kept losing their easy-on-ramps. So if you landed here looking for "managed QuestDB" or "QuestDB Cloud alternative," here is the honest list of what still exists, what each option costs you in setup, and where Layerbase fits in.

Contents

What QuestDB Cloud used to be

QuestDB Cloud, before it was retired, was the self-serve managed offering. You'd sign up, pick a region, get a connection string, and start writing rows over the InfluxDB line protocol or the PostgreSQL wire protocol. There was a free trial and pay-as-you-go pricing. People used it for dashboard backends, IoT pipelines, financial time-series, and exactly the kind of "try this in production" workloads that the new BYOC product makes very awkward.

The decision is understandable from QuestDB's side. Running a multi-tenant SaaS at low margins is hard. BYOC pushes the infrastructure cost back onto the customer's cloud bill, the customer signs a real contract, and QuestDB becomes a sustainable enterprise business. Good for them. Inconvenient for the developer who just wanted to point Grafana at a time-series database without owning an AWS account.

Option 1: Layerbase Cloud

Layerbase Cloud hosts QuestDB as one of its managed engines. You sign in, click create, pick QuestDB, and you get a connection string within a minute or so. It's PostgreSQL-wire compatible, so you connect with any standard pg client.

bash
psql "postgresql://admin:password@<your-host>.cloud.layerbase.dev/qdb?sslmode=require&sslnegotiation=direct"

One thing worth knowing about QuestDB on managed hosting: the sslnegotiation=direct parameter is required if your TLS terminates at a proxy (Layerbase uses HAProxy with SNI routing). That works with psql 17+ and most programmatic Postgres drivers. GUI clients like TablePlus and DBeaver do not currently support the parameter, so if your workflow is GUI-driven you'll want to use a CLI client or hit the QuestDB web console through the dashboard.

Scale-to-zero is on by default for free instances, which matters more for QuestDB than for most engines. QuestDB cold-starts the JVM, so the first query after an idle period takes a few seconds. Subsequent queries are normal speed. If that's not acceptable for your workload, the "Keep alive" toggle on a paid instance disables hibernation.

Layerbase Cloud is the recommended option if you want hosted QuestDB without standing up infrastructure. It's what I built first because the QuestDB Cloud shutdown was personally annoying.

Option 2: Run it locally with SpinDB

If your workload is local (development, prototyping, single-node ingest tests), SpinDB gives you the same QuestDB binary as a one-line install. No Docker, no Java setup, no JDK. SpinDB downloads the QuestDB binary for your platform and runs it as a managed process. (What is SpinDB?)

bash
npm i -g spindb        # npm
pnpm add -g spindb     # pnpm

Create an instance:

bash
spindb create quest1 -e questdb --start

Get the connection URL:

bash
spindb url quest1
text
postgresql://admin:password@127.0.0.1:8812/qdb

This is the local equivalent of QuestDB Cloud. It runs on your machine, listens on a random free port, and you connect with anything that speaks the PostgreSQL wire protocol. The QuestDB web console is on the HTTP port (192 above the PG port by default), and the InfluxDB Line Protocol ingest port is 197 above.

Stop and start it like any other SpinDB instance:

bash
spindb stop quest1
spindb start quest1
spindb list

For local time-series experimentation, this is probably the fastest path from zero to "I'm writing rows." No cloud account, no signup, no monthly bill.

Option 3: Layerbase Desktop

Layerbase Desktop is the same SpinDB engine wrapped in a Mac app. If you've ever used something like Postgres.app and missed having an equivalent for the rest of the database world, that's roughly what it is. You click "New instance," pick QuestDB, and it shows up in a list with a stop/start toggle, the connection string, and a quick-connect to the web console.

It's useful if you don't live in the terminal, or if you want to keep five different databases running on your laptop without remembering which one is on which port. For server workloads, ignore it. For weekend projects, it's the lowest-friction way to have a real QuestDB running locally.

Option 4: Self-host on a VM

The original answer. Provision a VM, install QuestDB from the tarball or the Docker image, open the ports you need, set up TLS, set up monitoring, and you have hosted QuestDB. It works and it's cheap if your traffic is low. The downside is that everything from TLS renewal to disk pressure alerts to JVM tuning is on you.

If you go this route, the QuestDB documentation has a reasonable production deployment guide. The two things that bite people are the JVM heap size (defaults are conservative) and the open-file limits on Linux (QuestDB likes a lot of file descriptors).

Option 5: QuestDB Enterprise BYOC

This is the official path now. You provide an AWS or GCP account, QuestDB deploys their managed stack inside it, and you get the production features (replication, RBAC, support SLAs). It's targeted at companies with serious time-series workloads where the operational support is worth more than the cloud markup.

If you fit that profile, this is probably the right answer and you should email QuestDB directly. If you're not sure whether you fit that profile, you almost certainly don't, and one of the first four options will serve you better until you do.

Which one to pick

For most readers, the decision tree is short:

  • Need a managed QuestDB right now without a sales call? Layerbase Cloud.
  • Just trying it out on your laptop? SpinDB.
  • Prefer clicking buttons to typing commands? Layerbase Desktop.
  • Have a production team and a real budget? Talk to QuestDB about Enterprise BYOC.
  • Love yak-shaving? Run it on a VM yourself.

QuestDB itself is still excellent. The shutdown of QuestDB Cloud was a business decision, not a quality issue. The column store is one of the cleaner time-series implementations out there, the InfluxDB Line Protocol support is fast, and the PostgreSQL wire compatibility means you can plug it into existing tooling without writing custom adapters. None of that changed. What changed is the on-ramp, which is what Layerbase Cloud and SpinDB are now filling.

If you want to go deeper on QuestDB itself, the getting started guide walks through ingesting time-series data with both the line protocol and the PG wire interface.

Something not working?