Run TiDB
on Kubernetes
Solanica Platform deploys and operates TiDB, the distributed, MySQL-compatible SQL database, on any Kubernetes cluster, in the cloud or in your own data center. Scale SQL, storage and analytics independently, with backups, TLS and monitoring handled for you. Built on the open-source OpenEverest project and TiDB Operator v2.
Three ways to run TiDB
TiDB is open source, so the question is who runs it and where. Here is how a managed cloud service, a do-it-yourself operator setup and Solanica Platform compare.
Inside a TiDB cluster
TiDB separates SQL, storage and scheduling into components that scale on their own. Solanica Platform gives each one its own replicas, CPU, memory and disk, so you can add query capacity without moving data, or add storage without touching the SQL layer.
SQL layer
TiDB
Stateless servers that speak the MySQL protocol, parse and plan queries, and push work down to storage. Add nodes for more concurrent connections.
- Default nodes2
- Storagenone
- Port4000
Storage layer
TiKV
A distributed, transactional key-value store. Data is split into regions, each kept in three copies with Raft, so losing a node loses no data.
- Default nodes3
- StoragePVC
- Copies3 (Raft)
Control plane
PD
The Placement Driver stores cluster metadata, hands out transaction timestamps and moves regions between TiKV nodes to balance load.
- Default nodes3
- StoragePVC
- RoleTSO · scheduling
Analytics · optional
TiFlash
Columnar replicas that follow TiKV in real time. The optimizer sends analytical queries here, so reports run on live data without an ETL pipeline.
- Default nodes0 (off)
- StoragePVC
- Replicatedper table
How it works
You describe the database you want as a single Instance in OpenEverest. The tidb provider turns it into a TiDB Operator v2 Cluster plus one group per component, reports health and connection details back, and keeps everything in the state you declared. The provider is open source: read the code in openeverest/provider-tidb.
See it in action
The same console your teams use for every other database, with the settings that matter for TiDB.
Guided provisioning
Configure the SQL, storage, PD and analytics layers step by step. A running summary shows every setting before you create the cluster.
- Sizing per component: nodes, CPU, memory, disk and storage class
- Backup schedules set up at creation time
- Inline TOML configuration for each component
Add analytics with TiFlash
Give TiFlash its own nodes, CPU, memory and disk to run real-time analytics on live transactional data. Leave it at zero until you need it, then mark the tables you want replicated.
- Columnar replicas kept in sync with TiKV
- Scale TiFlash in and out without touching OLTP nodes
- No separate data warehouse or ETL pipeline
Schedule backups
Take TiDB BR snapshots to any S3-compatible storage on demand or on a schedule. Keep a fixed number of copies or everything inside a time window, and restore into the same cluster or a brand-new one.
- Recurring schedules, run by the provider
- Retention by count or by time
- Restore into an existing or a new instance
Connect and operate
Check cluster status, copy MySQL connection details, and see the size and configuration of every component on one page. Edit any component in place to scale it or change its settings.
- Host, port 4000, user and a generated root password
- Per-component cards for TiDB, TiKV, PD and TiFlash
- Backups and restores in their own tabs
What's included
The operations you would expect from a managed TiDB service, running in your own cluster.
Distributed SQL at scale
Scale the SQL layer, TiKV storage and PD independently. Grow capacity by adding nodes instead of sharding your application.
Capabilities →HTAP with TiFlash
Add columnar TiFlash replicas to answer analytical queries on live transactional data, with their own CPU, memory and disk.
How TiFlash works →Backup and restore
On-demand and scheduled BR snapshots to S3-compatible storage, with count or time retention, and restores into an existing or a new instance.
Backup details →Safe Day-2 operations
Rolling upgrades in the order TiDB expects (PD, TiFlash, TiKV, then TiDB), online storage expansion, and TiKV scale-in that moves data off a node before removing it.
Day-2 details →Security
Mutual TLS between all components and TLS for MySQL clients, on by default. Certificates come from the provider or from cert-manager, and the root password is generated and kept in a Kubernetes Secret.
Security details →Monitoring
One toggle creates a Prometheus PodMonitor or a VictoriaMetrics VMPodScrape for PD, TiKV, TiDB and TiFlash, with a built-in TiDB dashboard in the console.
Monitoring details →Frequently asked questions
Is TiDB compatible with MySQL?
Yes. TiDB speaks the MySQL protocol on port 4000, so existing MySQL drivers, tools and ORMs connect to it as they would to MySQL. Every cluster gets a connection Secret with the host, port, user and password, plus the CA certificate when client TLS is on.
What runs under the hood?
The open-source tidb provider for OpenEverest translates an Instance into resources for TiDB Operator v2: one shared Cluster plus a group per component (PD, TiKV, TiDB and optionally TiFlash). The operator runs the pods; the provider never manages them directly.
How are TiDB upgrades handled?
Pick a newer TiDB version and the operator rolls it out in the order TiDB requires: PD, TiFlash, TiKV, then TiDB. Downgrades are rejected.
Can I add analytics to an existing cluster?
Yes. Raise the number of TiFlash nodes from zero, then choose which tables to replicate with ALTER TABLE … SET TIFLASH REPLICA 1. The optimizer sends analytical queries to TiFlash automatically.
How do backups work?
Backups are full TiDB BR snapshots written to S3-compatible storage you control. Run them on demand or on cron schedules with retention by count or by time, and restore into the same instance or seed a new one. Point-in-time recovery is on the roadmap.
Does it run on-premises or in air-gapped environments?
Yes. It runs on any conformant Kubernetes cluster, including on-premises and air-gapped sites. For air-gapped installs you mirror the images and install the TiDB Operator CRDs from your own copy.
How is Solanica Platform different from OpenEverest?
OpenEverest is the open-source project, and the tidb provider is part of it under the Apache 2.0 license. Solanica Platform is the enterprise distribution of OpenEverest: it adds RBAC and SSO, safe upgrades and 24/7 support from the team that builds it. See the Platform page for details.
From pilot to production
Our engineers work with your team from sizing the first cluster to running it in production.
Assessment
We look at your workloads, whether you are coming from MySQL, a sharded setup or a managed service, and size PD, TiKV, TiDB and TiFlash for them.
Pilot
You deploy on your own cluster, move a real workload over, and test scaling, backups, restores and monitoring against your requirements.
Production
We help you roll out with a repeatable setup that fits your GitOps workflow, and our team stays on hand for support.
Talk to us about your TiDB workloads
Tell us about your setup and we will connect you with the engineers who build and support the platform.
TiDB, TiFlash and TiDB Cloud are trademarks of PingCAP, Inc. MySQL is a registered trademark of Oracle and/or its affiliates. Solanica is not affiliated with, endorsed by, or sponsored by PingCAP, Inc. or Oracle. These names are used for identification purposes only.