MARIADB
REST API
Turn a MariaDB query into a secure REST API — no backend to build, no port 3306 to open.
Save a SQL query against your MariaDB database, mint a per-recipient API key, and hand a partner a live JSON endpoint. No PHP or Node app to write, no server to host, no firewall hole — just a governed, read-only MariaDB REST API in minutes.
Ask Nova, get SQL + charts
Meet Nova
One key per partner. No credentials shared.
Build an API
+more
Scheduled sync to 6+ platforms
Explore
+more
Query APIs with SQL, no code
Explore
+more
Claude, Cursor, ChatGPT & Grok talk to your data
Connect AIQuery Streams is a secure, real-time database integration platform that turns any saved MariaDB query into a partner-ready REST API endpoint — with per-recipient keys, read-only enforcement, and a full audit trail. You get a live MariaDB REST API without writing a backend, hosting a server, or opening port 3306 to the internet. Learn more at QueryStreams.com and sign up for free to publish your first MariaDB endpoint in minutes.
Why expose a MariaDB database as a REST API?
MariaDB powers a huge share of the web’s applications, and sooner or later something outside that application needs a slice of the data — a client wants their numbers in a dashboard, a vendor wants a live feed instead of a nightly CSV, a partner’s app needs to read one well-shaped result set. The usual answer is “write a small API.” So you stand up an Express, Laravel, or Flask app, add auth and rate limiting, deploy it somewhere, keep it patched, and now you own a service forever. The alternative — opening port 3306 and handing out a database login — is worse: that login can read everything, and you cannot revoke just one consumer. A MariaDB REST API built for sharing skips all of it: the partner gets a URL and a token, not a database account and not a server you maintain. Query Streams makes it a saved query plus a key.
No backend to build or host
No Express app, no Laravel controller, no Flask route. You do not write, deploy, or patch a service — the endpoint runs as a managed feature.
Per-recipient API keys
Every recipient gets their own qsapi_* key. Revoke one without touching the others, and without resetting a shared MariaDB password.
Read-only by design
A read-only validator rejects any non-SELECT statement before it reaches MariaDB. There is no accidental UPDATE, DELETE, or DROP path through the API.
Your SQL stays private
The recipient sees the endpoint URL, the JSON response, and any filters you exposed — never your SQL, your schema, or your table structure.
No open port 3306
The Agent connects outbound only. Your MariaDB server stays behind the firewall — no inbound port, no public database login.
Permanent, expiring, or self-destructing
Make an endpoint permanent, set it to expire on a date, or give it a fixed call budget that self-destructs after a set number of requests.
MariaDB data over REST — the usual ways, and why they hurt
There are real ways to put an HTTP surface on MariaDB, and plenty of teams build one. The catch is that every DIY path leaves you owning code, a server, or a database login you cannot scope tightly. Here is how the common approaches compare to a Query Streams shared endpoint when the goal is simply “let a specific partner read a specific result set.”
| Concern | DIY API (Express / Laravel / Flask) | Open port 3306 + DB login | Query Streams |
|---|---|---|---|
| What the recipient holds | A URL into your app | A MariaDB username + password | A single-purpose key for one query |
| Surface exposed | Whatever you hand-code | Every table the login can read | One saved query, nothing else |
| Network change required | Host + expose the app | Open inbound port 3306 | None — outbound-only Agent |
| Per-recipient keys + revoke | Build it yourself | Shared login | Built in |
| Audit log of every call | Add it yourself | Hard to attribute | Built in |
| You operate / patch / maintain | Yes, forever | Yes, plus exposure | Managed for you |
| Time to first endpoint | Days | Hours (and a security headache) | Minutes |
When a DIY API still makes sense
If you need full read-write access, custom business logic, or a public API product with many endpoints, a hand-built service is the right tool. Query Streams is for the far more common case: you just need to hand a named partner one governed, read-only result set — with its own key, an audit trail, and nothing to build or maintain.
How Query Streams turns a MariaDB query into a REST API
Once the Network Agent is installed and your MariaDB connector is configured, promoting a saved query to a shared REST endpoint takes about three steps. If you already use Query Streams for Excel, Google Sheets, or the MCP Server, your Agent and connector are already in place — you start at step two.
Connect MariaDB through the Agent
Install the Network Agent and add a MariaDB connector with a read-only user (a GRANT SELECT account is ideal). The Agent makes an outbound TLS connection to Query Streams — no inbound firewall rule, and no database login ever reaches a recipient.
Save a SQL query
Write the SELECT in the Query Builder against your MariaDB connection — JOINs, CTEs, window functions, and parameters all welcome. Name it and save. Anything you can SELECT can become an endpoint.
Promote it and share a key
Open the Install tab, choose the endpoint type (permanent, expiring, or call-budget) and output format, then invite a recipient by email. They get a magic-link claim and their own qsapi_* key.
Use a read-only MariaDB user
For defense in depth, point the connector at a MariaDB account created with GRANT SELECT on just the tables it needs. Query Streams already blocks non-SELECT statements, but a least-privilege login means even a misconfiguration cannot write. The same connector serves Excel, Sheets, the MCP Server, and your REST endpoints.
No open ports, no shared database login
The security model is the reason teams reach for this instead of opening 3306 or building yet another service. Your MariaDB credentials live only inside the Agent’s encrypted credential store on your network; they are never transmitted to our cloud and never visible to a recipient. On top of that, every endpoint gives you per-recipient controls you can tighten before you share.
Outbound-only Agent
The Agent connects out to agent.querystreams.com on port 443. Your network sees normal outgoing HTTPS — no inbound 3306, no VPN, no tunnel.
Read-only enforcement
A validator runs in the Agent, on your network, before any statement reaches MariaDB. Non-SELECT statements are rejected with READONLY_VIOLATION.
IP + CORS allowlists
Pin a recipient’s key to specific IPs or CIDR ranges, and restrict which browser origins may call each endpoint. Off-list calls are refused before any SQL runs.
Rate limits + byte quotas
Two-tier rate limits (per key and per endpoint) plus an optional monthly byte cap keep a noisy recipient inside a safe blast radius.
Call your MariaDB REST API
Recipients call the endpoint like any other REST API: a bearer token and a URL. Any saved-query parameter you exposed can be set per call — on the querystring for GET or in a JSON body for POST. The Agent binds those values as proper prepared-statement parameters, never string concatenation, so a recipient cannot break out of a filter to inject SQL.
Pick the output format per call with the Accept header (or a ?format= query parameter): JSON for a single array, CSV for spreadsheets and pandas, or, on a streaming endpoint, NDJSON (one JSON row per line) for parse-as-you-go pipelines over large result sets. For bandwidth-sensitive consumers, opt into LZ4 payload compression with Accept-Encoding: lz4; uncompressed responses also get standard gzip on the wire automatically. For the full breakdown of static vs streaming modes, the four wire combinations, and OpenAPI 3.1 generation, see the Instant REST API for SQL databases guide.
How usage is billed
The API Platform is included in every plan and draws from the same monthly byte allowance as Excel, Sheets, and the MCP Server — lz4 calls bill on compressed bytes, everything else on uncompressed. how data-realm billing works across transports →
Plug it into Power BI, Tableau, and anything that reads JSON
Because every endpoint returns standard JSON — with CSV and streaming NDJSON on tap — any tool that can read a REST feed consumes your MariaDB data directly, with nothing to install on their side and no database driver required. Power Query is the easiest bridge into the Microsoft BI stack: in Power BI choose Get Data → From Web, paste the endpoint URL, add your Authorization header, and Power Query parses the JSON into a refreshable table that feeds your data model. (For live data inside a spreadsheet, the native Query Streams Excel add-on is the simpler path — Power Query is there when you want the data in the Power BI model itself.)
Power Query
Get Data → From Web, paste the URL and bearer token, expand the JSON to a refreshable table
Power BI
Same Power Query engine — load the endpoint straight into your model and schedule refresh
Tableau
Point a Web Data Connector or JSON source at the endpoint for live dashboards
Postman
Import the OpenAPI 3.1 spec, then send, inspect, and share requests in one click
It also feeds n8n, Qlik, curl, Python (requests or pandas.read_json), Insomnia, Hoppscotch — or any script or workflow that can send an HTTP request and read JSON.
Works with managed MariaDB too
It does not matter where your MariaDB runs. The Agent connects the same way to a self-hosted MariaDB on a Linux box, a container, Amazon RDS for MariaDB, Azure Database for MariaDB, Google Cloud SQL, SkySQL, or any managed MariaDB host. For the lowest latency, run the Agent close to the database; one Query Streams account can run multiple Agents across machines and regions, and a single endpoint behaves identically regardless of which Agent serves it.
Running MySQL instead?
MariaDB began as a MySQL fork, and Query Streams treats them as one connector family — the same workflow exposes a MySQL database as a REST API with identical security and output options. It also promotes saved queries from PostgreSQL, Microsoft SQL Server, SQLite, Microsoft Access, Snowflake, Oracle, BigQuery, and DuckDB. Browse the Connector Setup guides for the full list.
Frequently Asked Questions
Do I need to open port 3306 or expose MariaDB to the internet? +
Can the recipient see my SQL or my database credentials? +
Is this just a MySQL connector? Does MariaDB work fully? +
What output formats can the API return? +
Accept header or ?format= — with optional LZ4 payload compression and automatic gzip on the wire. the output formats and wire combinations explained →Can the recipient run their own SQL or change my query? +
Does this work with Amazon RDS, Cloud SQL, or SkySQL? +
Can an endpoint expire or self-destruct? +
Get Started
Publish your first MariaDB REST API for free.
Sign up, install the Network Agent, connect MariaDB with a read-only user, save a SQL query, and email a recipient a magic-link claim. Per-recipient keys, read-only enforcement, and a full audit trail are on from the first call.
Related guides: Instant REST API for SQL databases | Expose MySQL as a REST API | Database REST API platform | Connector Setup guides
Category: API Platform
Tags: mariadb-rest-api, mariadb, rest-api, expose-mariadb-as-api, mariadb-api-integration, share-mariadb-data, per-recipient-keys, no-code-api, mysql-rest-api, database-rest-api
Meta Description: Turn a MariaDB query into a secure, read-only REST API with per-recipient keys — no backend code, no open port 3306, no shared login.
English 
Spanish 
German 
French 
Portuguese 
Japanese 
Korean 
Chinese 
Italian 
Dutch 
Indonesian 
Polish