Aster Web Data / Start here

Is it a fit?

The databases, query options, writes, security and deployment Aster Web Data supports, to check against your requirements before you adopt it.

Before you build an application's API on Aster Web Data, check that it covers what your screens and your operations team will ask of it. The lists below give what is supported, and each links to the page with the detail.

Databases

Aster Web Data serves data from PostgreSQL, MariaDB, SQLite and DuckDB, and in the Commercial edition from SQL Server, Oracle and Db2. TigerBeetle Preview is supported as a ledger with a fixed catalog of accounts and transfers. Databases compares them, and each database has its own page with the versions it runs on and how it behaves.

One service can publish sets from several of these databases, and one request can read across them: a customer from PostgreSQL with their invoices from MariaDB, for example. Reads across databases gives what runs where.

Queries

Clients send OData 4.01 requests, which carry everything a list screen, a detail screen or a report asks for:

• $filter with comparisons, and, or and not, string and date functions, arithmetic, and conditions on related records (customer/region eq 'EU', invoices/any(i: i/paid eq false)).
• $orderby, including by a related record's field, and $top, $skip and $count for pages with a total. Server-driven paging caps the page size.
• $select and $expand, with $filter, $orderby, $top, $skip and $count inside an $expand.
• $apply for grouped totals: groupby and aggregate with sum, minimum, maximum, average and distinct count.
• Hierarchies, with ancestors, descendants and traverse.
• Navigation paths such as Customer(1)/invoices.

The service publishes its $metadata and an OpenAPI 3.1 description built from the same model. OData support lists every option and function.

Writes

• Create, update and delete on each set, and a set can refuse any of them in its definition.
• Deep inserts: a parent and its owned children in one request.
• $batch in JSON. The requests in an atomicity group run in one transaction and are rolled back together.
• Optimistic concurrency with ETags: an update with a stale If-Match is refused with 412. The tag is a version column, an expression, PostgreSQL's row version, or a counter the server keeps.
• Many-to-many relations through a link table.

A changeset that writes to two databases is refused before anything runs.

Security

• Authentication. JWT bearer tokens, verified with a secret, a PEM public key or a JWKS file. A request without a token is anonymous.
• Access per set. Read, insert, update and delete, each allowed by role, to any authenticated caller, or to nobody.
• Row ownership. A set can name an owner property, so each user reads and writes only their own rows.
• Rules. Rules over the caller's claims, the request and the data decide what may be read or written, and validate a write before it runs.
• Row-level security in PostgreSQL. Each transaction carries the caller's user and roles as settings, so your own policies can use them.

Authentication and access and Rules give the detail.

Your own logic

• Actions and functions written as Python or TypeScript scripts and bound to a set (Operations in code).
• Virtual data sources: a script serves a set from somewhere other than SQL, such as a REST API, and clients query it like any other set (Virtual data sources).

Deployment

• One server process and a YAML configuration file. Database URLs, passwords and the JWT secret come from environment variables or files.
• TLS to PostgreSQL and MariaDB, up to verify-full against your CA.
• Health checks and Prometheus metrics, which can be served on a separate port, and OpenTelemetry traces.
• A database that is down makes only its own sets answer 503, and the server reconnects when it returns.
• A changed model or configuration applies on SIGHUP, without a restart.
• Graceful shutdown that lets a load balancer drain the server first.

Configure and deploy covers each of these.

When another tool fits better

• Your clients need a query language other than OData, such as GraphQL.
• Your data is in a database that is not listed above.
• The API is a few fixed endpoints over one table that will not change. Hand-written endpoints are simpler.
• The main work is a process that does not sit on the data, such as a long-running workflow. Aster Web Data runs rules and scripts on requests for data.

To try it, Get started serves a SQLite file in a few minutes.