Compatibility
Realfuture connects catalogs, AI, Flink and Flink CDC, lakehouse storage and analytics across your infrastructure. Compatibility belongs to a specific combination of releases and workflows: catalog discovery, native queries, SQL processing and CDC replication can have different requirements for the same system.
Managing an existing Flink runtime and using commercial runtime enhancements may have different requirements. Confirm which path applies to your deployment and whether any component must change.
Prepare a component inventory
| Component | Record for the evaluation |
|---|---|
| Realfuture | Product release, licensed components and deployment topology |
| Flink | Exact version, distribution, JDK, workload API and state backend |
| Flink CDC | Version, SQL connector or Pipeline API, and required features |
| Catalogs and queries | Catalog type, supported object operations, metadata refresh and query execution path |
| Lakehouse and analytics | Paimon, Fluss, Doris or StarRocks versions, connectors, table types and maintenance requirements |
| AI providers | Endpoint, protocol, enabled models, tool support, data policy and edition entitlement |
| Sources and targets | Product and version, read/write direction, authentication and networking |
| Connectors | Artifact versions, dependencies, formats and required data types |
| Infrastructure | Kubernetes or YARN version, deployment mode, storage and resource limits |
| Platform services | Platform database, identity integration, monitoring and backup requirements |
For multiple runtime clusters
One platform can manage multiple YARN and Kubernetes targets. Record the configuration for each target, including cluster access, namespace or queue, runtime identity, Flink version, dependencies, storage and the route used to reach job services.
Check access from the platform to each target and from each job to its sources, sinks and state storage. A job that runs on one cluster still needs its dependencies, credentials and storage paths validated before moving to another.
For catalogs and AI
Verify the catalog operations used by your workflow: discovery, DDL, schema refresh, queries and the table context supplied to AI. Catalog connectivity alone does not validate runtime connector access.
Configure the model provider and test the required generation or diagnosis task, including streaming responses and tool calls where used. Review the selected schemas, editor content and diagnostic evidence that may be sent to that provider. See AI assistance.
Ask for the release-specific compatibility list before making a production decision. Do not infer support for a combination from separate claims that each individual component is supported.
For CDC pipelines
Use representative tables to check:
- Initial snapshot and transition to incremental changes.
- Data types, primary keys, time zones and update/delete behavior.
- The DDL changes you need and the target system’s response.
- Restart, catch-up and recovery after source, target or network failures.
- Data correctness and delivery semantics for the complete source-to-target path.
Schema evolution and delivery guarantees depend on the connector and configuration. A successful test for one pair does not certify another pair.
For platform integration
Confirm API coverage and authentication, role permissions, monitoring export and the ownership of any additional integration work. Distinguish packaged product behavior from an external integration or a separately scoped engineering service.
Continue with the evaluation guide or migration guide.