Skip to content
sandadocs

sanda warehouse

A standard PostgreSQL database in Sydney where everything you connect or upload lands, and where your models are built.

Your sanda warehouse is a dedicated PostgreSQL database that sanda provisions, tunes and runs for you. Every connection and CSV upload lands in it. Your own views and procedures are built in it. The semantic fluid, cherry, reports and sanda search all read from it.

It runs in Sydney, and it is a standard database on purpose: the tables are ordinary PostgreSQL tables, the SQL you write is ordinary PostgreSQL, and you can take a full copy with you.

How many warehouses you can have

A workspace holds one or more warehouses, depending on its edition. Each connection chooses which warehouse its rows land in. A trial has the limits of Standard.

Basic Standard Enterprise
Warehouses in a workspace 1 3 50
Storage in each warehouse 10 GB 100 GB 16 TB
Concurrent queries in each 60 60 300
Longest single statement 60 seconds 60 seconds 5 minutes

These are the most a warehouse can be set to. You can set any of them lower on a warehouse as a spend guard (see Usage, budgets and suspension). The full list of limits is in Limits.

The sanda learning dataset does not count towards your warehouse limit. It is a free, read-only sample that sanda attaches to every workspace: a specialty-foods importer with ten years of trading behind it, already modelled. It appears in the Explorer tagged sample, it is not metered, and you cannot run SQL, build models or optimise on it. Remove it with Remove dataset on its own card, and add it back with Add it at the bottom of the Warehouse page.

How a warehouse is laid out

Every warehouse has the same shape, so you and cherry never have to guess where something is. Each schema has one job.

Schema What it holds Who writes to it
raw Landing tables: every stream a connection syncs, as it arrived, and every CSV you upload. sanda's managed sync and CSV loader. You can read it.
derived Yours: the views, materialized views and procedures you define, and any tables your own SQL creates. You, through Modelling or the SQL shell.
mapping Modelled: the views the semantic fluid publishes so that cherry, reports and search can query them. sanda, when you put a table on the fluid.
search Indexed: the text that sanda search keeps searchable, one table per search service. sanda.
meta Bookkeeping: the cursors and version records sanda keeps for itself. sanda.

A landing table is named raw.<connection>__<stream>: the connection's name in lowercase with anything that is not a letter or digit turned into an underscore, two underscores, then the stream. A connection called Xero with an invoices stream lands as raw.xero__invoices. A CSV called sales lands as raw.csv__sales. The SQL reference has the full naming rules.

Storage and compute

You pay for two things a warehouse uses, and the console shows both on the Warehouse page.

Storage is the size of the whole database, including indexes and search indexes, in GB. sanda measures it exactly and bills the GB-months you actually held, at A$1.06 per GB-month. A warehouse that held 40 GB for half a month and 60 GB for the rest is billed 50 GB-months.

Compute is the work your warehouse does, counted in compute hours. One compute hour is one vCPU running for an hour. The warehouse scales up under load and down to nothing when nobody is asking. sanda counts the minutes it was kept awake for you (each awake minute counts at half a vCPU, the floor), plus the larger of two figures: the work your queries did, or the seconds recorded for builds, procedure calls and scheduled tasks. Compute is billed at A$0.483 per compute hour used.

Readings are taken when anyone opens the Overview or Warehouse page (a warehouse read in the last 45 seconds is skipped), when an owner or admin presses Measure now, and about hourly in the background, so a workspace nobody signs in to is still measured. Billing usage shows how these readings become an invoice.

The Warehouse page

Open Data · Warehouse. Each warehouse is a card.

On the card What it does
Name and status The database name, and a status: provisioning, healthy or error. A capacity · warning pill appears when it is past 80% of a limit and capacity · over when it reaches one. A suspended · budget or frozen · trial pill appears when the workspace is suspended.
Explore Opens the Explorer on this warehouse.
Optimise Recommends index, vacuum and statistics changes.
SQL shell Opens sanda sql.
Storage and Compute meters What this warehouse holds and runs today, against its limits, with the number of rows and tables and when it was last measured.
Run rate What the warehouse is running up, carried across a month at today's usage. It is an estimate; the invoice adds up the real readings.
Measure now Takes a reading immediately.
Limits Sets this warehouse's own storage, compute, concurrency and statement limits, at or below your edition's.
Sample model For a warehouse that holds sanda's sample tables. It adds their relationships, metrics and layout to your workspace's model.
Delete warehouse Drops the database and everything in it. Disabled while a connection still lands there.
Storage held and Compute run charts The last 30 days, one reading per day.

Above the cards, New warehouse provisions another one, and Explore opens the Explorer across all of them.

Every member can read this page. Owners and admins provision, measure, change limits and delete.

Reaching your data

sanda connects to your warehouse for you and never hands out a database password, so there is no connection string to paste into other tools. You reach the data through:

  • the Explorer, to browse schemas, columns and sample rows;
  • sanda sql, to run your own SQL as an owner or admin;
  • Modelling, to build views and procedures;
  • the OData feed, to pull tables into Excel or Power BI;
  • a full copy, if you want to leave with your data.

Something unclear or out of date? Tell us, and we will fix the page.