01 — Mission
What we are trying to do
The premise of Tellus is simple: the databases powering modern software are excellent. The tools for managing them together are not. A developer building a product in 2026 may be running a PostgreSQL database for their core transactional data, a document store for flexible content, a real-time database for collaborative features, and a vector database for search. Each of these is a rational, considered choice. Each solves a specific problem well.
But managing them means maintaining accounts on four different platforms, learning four different console interfaces, storing four sets of credentials, and context-switching between four entirely different UI paradigms every time something needs attention. This is not a problem with any of the individual databases. It is a problem with the absence of a unifying management layer above them.
Tellus is that layer. It connects to your existing databases — wherever they are hosted, whatever provider you use — and exposes them through a single, consistent interface. You connect a database to Tellus the same way regardless of whether it is a MySQL instance running on a VPS, a MongoDB cluster on Atlas, a Firestore collection in Firebase, or a serverless Neon database. Once connected, you interact with all of them the same way.
Our mission is not to replace the databases you use. It is to make the experience of working across multiple databases as simple and safe as working with one. We believe that the management overhead of a multi-database architecture should be proportional to its value — not to the number of providers you happen to use.
02 — Origin
Why we built it
Tellus was built out of direct experience with the problem it solves. The pattern is consistent across engineering teams of every size: as an application grows in complexity, it accumulates database systems. Each one is added because it is genuinely the right tool for its use case. And each one brings with it a new console to learn, a new set of credentials to manage, and a new operational context to maintain.
The friction compounds over time. What begins as two or three database tabs open in a browser grows into a sprawl of credentials distributed across .env files, team wikis, and messaging platforms. Debugging an issue that spans two database systems requires opening both consoles simultaneously and mentally correlating data presented in completely different visual formats. Onboarding a new engineer means giving them credentials and contextual knowledge for every database system individually.
The existing solutions were insufficient. Local database clients like TablePlus or DataGrip support multiple database types but require credentials to be stored locally, do not support team collaboration, and do not provide any AI-powered analysis or health monitoring. Provider-specific consoles are excellent within their own ecosystem but offer no cross-database capability by design. No tool existed that treated the multi-database estate as a first-class object to be managed holistically.
Tellus is the answer to that gap. It is designed for the reality of how modern software is actually built — across multiple providers, by teams, with security requirements that go beyond storing credentials in a text file.
The specific workflow we set out to fix
Debugging across database systems
Tracing an issue through a system that spans multiple databases — finding the user record in one, the related event log in another, the cached state in a third — currently requires three consoles open simultaneously and manual data correlation. Tellus makes this a single-interface operation.
Credential management across the team
Production database credentials belong in exactly one place: a tightly controlled, access-audited secrets system. In practice they end up everywhere. Tellus replaces the distributed credential model with a centralised, encrypted, server-side store. Credentials are never on developer laptops, never in messaging tools, and never exposed to the browser.
Understanding database health proactively
Most teams discover database problems reactively — after a user reports slowness, after a query starts timing out, after a table grows large enough to cause issues. Tellus's AI health scanner provides proactive analysis: schema design recommendations, index gaps, data quality issues, and performance warnings, surfaced before they affect users.
Onboarding engineers to a multi-database stack
In a five-database environment, a new engineer currently needs to be given credentials for each system, introduced to each console interface, and taught the operational context for each provider. With Tellus, they are added to a Workspace, given an appropriate role, and they interact with all databases through one interface they learn once.
03 — The platform
What Tellus does today
Tellus is currently in public beta. The following describes what is live and available now, what is in active development, and what is planned for future releases. We publish this openly because we believe users should know exactly what they are getting — and what they are not yet getting — when they choose to connect a database to the platform.
| Feature | Status | Description |
|---|---|---|
| Multi-provider database connections | Beta | Connect MySQL, MongoDB, Firebase/Firestore, Neon PostgreSQL, and Supabase databases to a single Tellus account. Each database becomes a Project managed from one dashboard. |
| Schema browsing | Beta | View table structures, column definitions, data types, indexes, and constraints for any Connected Database. Schema metadata is cached server-side and refreshed on demand. |
| Record read, write, update, delete | Beta | Browse, search, and paginate table data. Insert new records, modify existing ones, and delete records through a unified form interface that adapts to the schema of any provider. |
| AI database health scanner | Beta | On-demand analysis of database schema design, index coverage, data quality, and performance indicators. Produces a health score with prioritised recommendations powered by a cascade of third-party LLM providers. |
| Natural language query assistant | Beta | Ask questions about your database in plain language. The Aria agent interprets your question, generates the appropriate query, and presents the results in a readable format. |
| Workspace collaboration | Beta | Invite team members to a Workspace, assign roles with appropriate permission levels, and share Project access without sharing credentials. Each member authenticates individually. |
| Automated report generation | Beta | Generate structured reports on database health, schema structure, and data summaries. Reports are stored within the Project for review and comparison over time. |
| Independent security audit | Planned — v1.0 | Third-party penetration testing and security review of the platform's credential handling, access control implementation, and data transmission model. |
| SOC 2 Type I certification | Planned — v1.0 | Independent verification of the platform's security, availability, and confidentiality controls. Required before the platform is recommended for production database connections. |
| Cross-database query and join | Planned — v1.5 | Execute queries that span multiple Connected Databases and receive results in a unified format. Enables data correlation across providers without leaving the Tellus interface. |
| Real-time change monitoring | Planned — v1.5 | Subscribe to data changes in Connected Databases and receive notifications within the platform when specified conditions are met. |
| Self-hosted deployment | Planned — v2.0 | Run Tellus within your own infrastructure for organisations with strict data residency requirements or that require the platform to operate within a private network boundary. |
04 — Audience
Who Tellus is built for
Tellus is built for anyone who manages more than one database system and finds the operational overhead of doing so disproportionate to the value it delivers. The platform is designed to serve several distinct user types, each of whom experiences the multi-database management problem in a different way.
User type 01
Full-stack and backend engineers
Engineers who are responsible for the databases their applications depend on, in addition to building the application itself. They are proficient with SQL and document queries but spend more time than they should navigating provider consoles and managing credentials across multiple systems.
- Debugging production issues that span multiple databases
- Verifying data integrity after deploys
- Seeding staging environments from production data
- Monitoring table growth and index usage
User type 02
Engineering teams and technical leads
Teams managing a shared database estate across multiple projects or services. The lead is responsible for access control — ensuring the right people have access to the right databases with the right permissions — without distributing credentials insecurely.
- Onboarding new engineers without sharing raw credentials
- Maintaining role-based access across the team
- Getting a unified view of database health before releases
- Standardising the operational model for all databases
User type 03
Agencies and independent developers
Developers managing databases on behalf of multiple clients. Each client may use different database providers, requiring the developer to maintain separate credentials and learn the specific console of each provider for each client engagement.
- Managing a portfolio of client databases from one place
- Switching between client environments without re-authenticating
- Generating health reports for client review
- Auditing data quality before client deliverables
Who Tellus is not appropriate for — yet
Tellus is currently in public beta. This means it is not yet appropriate for teams whose database management workflows are subject to compliance requirements — HIPAA, GDPR-regulated personal data under a formal data processing agreement, PCI-DSS cardholder data, or SOC 2 audit scope. These use cases require compliance certifications and formal documentation that Tellus does not yet provide. We are actively building toward them. Until those certifications are in place, Tellus is recommended for development environments, staging systems, and internal tooling where the data being managed is not subject to these regulatory requirements.