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

Short version: Layerbase Cloud is the managed QuestDB you can sign up for today without a sales call, and the Layerbase CLI or Layerbase Desktop covers the same engine locally if the workload is development. Self-hosting on a VM still works and still means owning TLS, monitoring, and JVM tuning. QuestDB's own Enterprise BYOC is the right answer only if you have a cloud account, a budget, and a procurement process.

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.

Status re-checked 2026-08-25 on questdb.com/cloud: still no self-serve signup and no published pricing, only an Enterprise trial and BYOC behind a sales contact form.

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

• The options at a glance
• What QuestDB Cloud used to be
• Option 1: Layerbase Cloud
• Option 2: Run it locally with the Layerbase CLI
• Option 3: Layerbase Desktop
• Option 4: Self-host on a VM
• Option 5: QuestDB Enterprise BYOC
• Which one to pick
• FAQ

The options at a glance

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.

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

That is the whole connection string: the hostname on the standard Postgres port with sslmode=require, so psql, programmatic drivers, and GUI clients like TablePlus and DBeaver all connect normally. One thing worth knowing: do not add sslnegotiation=direct to it. That parameter is only for connecting on the database's own dedicated port, and on the standard port it makes the TLS handshake fail.

QuestDB is a Pro-plan engine here and runs always-on rather than scaling to zero, which matters more for QuestDB than for most engines: it cold-starts the JVM, and an ingest pipeline should never land on a sleeping database. Ingest is ILP over HTTP on a dedicated HTTPS endpoint, authenticated with your database credentials, so the official QuestDB clients connect from the config string in the dashboard. One limit to know if you are moving a QuestDB Cloud or Telegraf pipeline across: raw ILP over TCP on port 9009 is not exposed, so switch the client to the HTTP transport. The ILP ingest guide covers the endpoints and limits.

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 the Layerbase CLI

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

npm i -g layerbase     # npm
pnpm add -g layerbase  # pnpm

Create an instance:

lbase create quest1 -e questdb --start

Get the connection URL:

lbase url quest1

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 local instance:

lbase stop quest1
lbase start quest1
lbase 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 desktop 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. It is also the only managed option here that branches QuestDB: fork the store, test the retention change on the fork, delete it. (The Layerbase CLI and Desktop run the same branching locally.)
• Just trying it out on your laptop? The Layerbase CLI.
• 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 the Layerbase CLI are now filling.

FAQ

Is QuestDB Cloud still available?

No. It stopped accepting new signups, the AWS Marketplace listing is dead, and the cloud page now routes to an Enterprise trial and the BYOC product behind a sales contact form. Checked again on 2026-08-25 and nothing has changed: there is no self-serve tier and no published pricing.

What happened to QuestDB Cloud?

QuestDB retired the self-serve managed offering in favour of Enterprise BYOC, where you bring an AWS or GCP account and QuestDB's team manages the deployment inside it. The reasoning is easy to understand from their side, since running a multi-tenant SaaS at low margins is hard and BYOC pushes the infrastructure cost onto the customer's cloud bill against a real contract. It just leaves the individual developer with nowhere to click.

Where can I get managed QuestDB without talking to sales?

Layerbase Cloud hosts QuestDB as one of its managed engines: sign in, click create, pick QuestDB, and you have a connection string within a minute or so. It speaks the PostgreSQL wire protocol, so any standard pg client connects to it.

Can I still run QuestDB for free?

Yes, locally. The Layerbase CLI downloads the QuestDB binary for your platform and runs it as a managed process, with no Docker, no JDK, and no account. lbase create quest1 -e questdb --start is the whole setup, and for local time-series experimentation it is the fastest path from zero to writing rows.

Do I need sslnegotiation=direct to connect to managed QuestDB?

Not with the connection string the dashboard gives you. The hostname on the standard Postgres port takes sslmode=require and nothing else, which works in psql, programmatic drivers, and GUI clients alike. The parameter only applies if you connect on the database's own dedicated port, which needs psql 17 or newer; adding it to the standard string makes the handshake fail.

Is QuestDB still worth using?

Yes. The shutdown of QuestDB Cloud was a business decision, not a quality problem. The column store is one of the cleaner time-series implementations available, the InfluxDB Line Protocol ingest is fast, and PostgreSQL wire compatibility means existing tooling plugs in without custom adapters. What changed is the on-ramp, not the engine.

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