Summary
- Thinfinity Workspace needs an external database in production; the built-in local database is for evaluation only, and MySQL is the preferred engine.
- Cybele recommends two databases: one for profiles and configuration (access profiles, RBAC, authentication mappings), which is mission-critical and should run with high availability, and one for analytics and the audit log, sized to your retention and compliance requirements.
- On Oracle Cloud Infrastructure (OCI), MySQL HeatWave provides managed MySQL with high availability across availability domains or fault domains, automated backups with point-in-time recovery, and patching handled by Oracle. Thinfinity does not need the HeatWave analytics cluster.
- Placing the DB system in the same region as the Thinfinity brokers, on a private subnet only they can reach, keeps authentication latency low and data in-region.
- A self-managed MySQL cluster still fits teams that need full engine control and have the expertise to run HA and tested restores.
Thinfinity Workspace keeps its configuration and its activity records in databases: access profiles, role-based access control (RBAC) rules, and authentication mappings on one side, analytics and the audit log on the other. In production, those databases have to be external. The built-in local database, Absolute Database, is for evaluation only, and MySQL is the preferred engine. When a Thinfinity Workspace deployment runs on Oracle Cloud Infrastructure, the managed option is MySQL HeatWave on OCI. This article explains what the service provides, how it compares with running a MySQL cluster yourself, how Cybele recommends laying out Thinfinity’s two databases on it, and when a different choice makes more sense.
What is MySQL HeatWave on OCI?
MySQL HeatWave is Oracle’s fully managed MySQL service on OCI. It was previously called Oracle MySQL Database Service, a name that still appears in older documentation. Each deployment is a DB system: a managed MySQL server that Oracle provisions, backs up, patches, and monitors. According to Oracle, it is the only cloud MySQL service built on MySQL Enterprise Edition.
What does Oracle manage for you?
Oracle handles provisioning, patching and upgrades, and monitoring of the DB system. High availability is optional and set per DB system: when it is enabled, the service runs three MySQL instances and promotes a secondary automatically if the primary fails. In regions with several availability domains, the instances are placed in different availability domains when the DB system uses a regional subnet; in single-domain regions, they are placed in different fault domains. Automated backups support point-in-time recovery. Data at rest is encrypted with Oracle-managed keys by default, or with your own keys, and client connections can use TLS.
Oracle automates tasks such as backup and recovery, and database and operating system patching. You are responsible solely for managing your data, schema designs, and access policies.
Does Thinfinity need the HeatWave analytics cluster?
No. The service is called MySQL HeatWave, but HeatWave is also the name of an optional in-memory analytics cluster that can be attached to a DB system. Thinfinity only needs the MySQL DB system, not the HeatWave analytics cluster. Thinfinity reporting comes from its own Analytics add-on, which reads from Thinfinity’s analytics and audit database.
Why is running a self-managed MySQL cluster so demanding?
Running MySQL yourself, on your own hypervisor or on cloud instances, gives you complete control of the engine. That control is real and valuable. The trade-off is that every responsibility a managed service absorbs becomes yours. You own the high-availability design, typically some combination of InnoDB Cluster or Group Replication with an async replica and a proxy or router such as MySQL Router. You own failover behavior, including the awkward failure modes: split-brain scenarios, replication conflicts, and quorum management that only surface under load or during a network partition. You also own backups and, more importantly, tested restores. A backup that has never been restored is a hope, not a recovery plan. Add patching and upgrades, security hardening, capacity planning and scaling, monitoring, and performance tuning, and the picture is a standing operational commitment with on-call risk. None of this is a reason to avoid self-managing MySQL, but it is the honest cost of the control you gain.
Test backup procedure to make sure your team can rapidly restore data both fully and partially, and to ensure you can roll back data at least seven days if needed.
Self-managed MySQL cluster vs MySQL HeatWave on OCI
| Dimension | Self-managed MySQL cluster (DIY on VMs/IaaS) | MySQL HeatWave on OCI |
|---|---|---|
| HA / failover | You design and operate InnoDB Cluster / Group Replication plus a router; you own split-brain and quorum edge cases | Managed HA across availability domains or fault domains, operated by Oracle |
| Backups / PITR | You script backups and, critically, test restores yourself | Automated backups with point-in-time recovery built in |
| Patching / upgrades | Your responsibility, including maintenance windows and rollback plans | Managed by Oracle |
| Security features | You harden the engine and add tooling; enterprise features require extra work or licensing | Encryption at rest (Oracle-managed or customer keys) and TLS in transit, managed by Oracle |
| Analytics and audit database | A second database you provision, back up, and operate | A second managed database, sized to your retention requirements |
| Scaling | Manual capacity planning and re-architecture | Shape and storage changes from the OCI Console (a shape change restarts the DB system) |
| Ops burden | High; standing team commitment with on-call risk | Low; Oracle operates the platform |
Why does Cybele recommend MySQL HeatWave for Thinfinity on OCI?
Cybele recommends two databases for Thinfinity Workspace in production. The first holds profiles and configuration: access profiles, role-based access control (RBAC), and authentication mappings. It is mission-critical, because the brokers depend on it to authenticate users and apply their access, and the Thinfinity manual strongly recommends running it with high availability. The second holds analytics and the audit log. It is not mission-critical, so its high availability, retention, and rotation are defined by your compliance requirements. On OCI, MySQL HeatWave covers both without adding database operations to your team. The profiles and configuration database gets managed high availability and point-in-time recovery, and the analytics and audit database can be sized to the retention you need. When the DB system runs in the same region as the Thinfinity brokers, authentication queries do not leave the region, which keeps latency low, and the data stays in that region.
How does Cybele recommend deploying MySQL HeatWave for Thinfinity on OCI?
When Thinfinity Workspace runs on Oracle Cloud, the database layer follows the Thinfinity Workspace database requirements. The goal is a database that only the Thinfinity brokers can reach, highly available where it matters, and recoverable. These are the steps:
- Create the MySQL HeatWave DB systems in the same OCI region as the Thinfinity brokers, on a private regional subnet, with port 3306 open only to the brokers.
- Use two DB systems: a high-availability DB system for the profiles and configuration database, and a standalone DB system for the analytics and audit database, sized to your retention requirements. A high-availability DB system runs three instances, so keep it for the data that is mission-critical.
- Create a dedicated MySQL user for Thinfinity with permissions to create tables and perform CRUD operations. OCI IAM governs the DB system itself; Thinfinity connects with this MySQL user, not with IAM credentials.
- Connect Thinfinity from the Database tab of the Configuration Manager, assigning each component to its database.
- Confirm automated backups with point-in-time recovery, and validate the restore path against the recovery objectives, not just the backup schedule.
This pattern sits naturally alongside our native OCI VDI for enterprises architecture and our Universal ZTNA access model, so the database, the access plane, and the virtual desktops share one region and one network boundary.
When a self-managed cluster or another engine makes sense
MySQL HeatWave is Cybele’s recommendation for Thinfinity on OCI, not the only option. Thinfinity also supports PostgreSQL, SQL Server, and MariaDB, on-premises or as managed services. If your Thinfinity deployment runs on another cloud, use that cloud’s managed MySQL or another supported engine. A self-managed cluster still fits when you need full control of the engine, for example a specific MySQL version or build, custom plugins, storage-engine tuning, or configuration that a managed service intentionally does not expose. Teams with in-house database operations expertise and a real requirement for that level of customization can run a cluster well. The rule is to match the platform to where the workload runs, how much control you need, and how much operational burden you want to own.
Frequently Asked Questions
Why not just run a MySQL cluster ourselves?
You can, and it gives you full control of the engine. The cost is that you own HA design, failover, backups with tested restores, patching, security hardening, monitoring, scaling, and on-call risk. A managed service removes that burden; a self-managed cluster keeps the control and the responsibility.
Does Thinfinity need a separate analytics database?
Yes. Cybele recommends a separate database for analytics and the audit log. Thinfinity’s Analytics add-on reads from that database, and keeping it apart from the profiles and configuration database lets you set its retention and rotation by compliance requirements without touching authentication. The HeatWave analytics cluster is not involved.
Why does Cybele recommend it for Thinfinity's profiles database?
Because the profiles and configuration database is mission-critical: the brokers depend on it to authenticate users and apply access profiles. MySQL HeatWave gives it managed high availability, automated backups with point-in-time recovery, and patching handled by Oracle, without adding database operations to your team.
Is my data kept in-region?
When the DB system runs in the same OCI region as your brokers, data stays in that region. Choose the region with your data residency requirements in mind.
What security features come with it?
Data at rest is encrypted with Oracle-managed keys by default, or with your own keys, and client connections can use TLS. OCI IAM governs the DB system; Thinfinity connects with a dedicated MySQL user. Placing the DB system on a private subnet that only the brokers can reach limits network access.
Does adopting it increase operational overhead for our team?
It reduces it. Oracle handles provisioning, high availability, backups with point-in-time recovery, patching, upgrades, and monitoring. Your team keeps the tasks that belong to Thinfinity: creating the databases and the MySQL user, connecting them in the Configuration Manager, and testing restores.
Talk to Cybele about your OCI data layer
If you are planning or already running Thinfinity Workspace on Oracle Cloud, we can help you design its databases on MySQL HeatWave, with high availability where it matters and retention sized to your compliance requirements. Request a demo to see it in action, or talk to an architect about your specific requirements.
