Your questions, answered.

EngineGrids Accelerator sits between applications and their existing databases. It serves eligible reads from memory and uses committed database changes from CDC to maintain the cache. The database remains the system of record. Explore the Accelerator.

Applications connect to an Accelerator endpoint, which connects to the database. The Accelerator can answer eligible reads from its cache and sends database work through to the existing database as needed. A cluster places multiple Accelerator nodes behind a shared application endpoint. See the reference architectures.

Teams facing database cost pressure, growing application demand, or repeated database reads can use an evaluation to assess the fit. Business buyers can examine cost and capacity, architects can assess application behavior, and operators can plan deployment and monitoring. Partners can bring these activities together in a customer engagement.

Repeated reads consume database resources that could serve other work. Answering reusable queries from the Accelerator can reduce that demand and improve application response. The business opportunity is more capacity from your existing investment, a smaller database footprint, or a combination supported by your measurements.

Both are valid goals. You can evaluate a smaller database footprint that still meets your performance targets, or keep the existing capacity to serve more demand and defer expansion. Compare the options using your workload, operating requirements, infrastructure prices, and license agreements. Explore the business value.

No. Database CPU reduction measures less processing work; spending depends on the resources you actually provision, license terms, cloud prices, and operating costs. Build the financial case from a configuration that meets your performance goals, and include the Accelerator and related services in the comparison.

Start with current database and infrastructure costs, license commitments, workload demand, response times, throughput, and growth expectations. Compare those with measured results and a proposed deployment. Separate savings from resources you can remove from capacity you can reuse, and include implementation and ongoing operation in the plan. See the cost-optimization approach.

EngineGrids supports MySQL, MariaDB, PostgreSQL, Microsoft SQL Server, Oracle Database and IBM Db2 for Linux. Explore the database engines.

Plan the server version, native driver, TLS settings and CDC prerequisites together. EngineGrids can help review your database environment and package choice. Discuss your deployment.

Transparent read acceleration uses your existing database drivers and updated connection settings. Point the application at the Accelerator address and port, then reconnect. Optional write queuing changes when some writes are acknowledged, so evaluate that setting separately against your application’s behavior. Read the connection guide.

No data migration is required for transparent read acceleration. Your data stays in your existing database, which remains the system of record. The Accelerator adds a layer to the application’s connection path; it does not replace the database or its availability and backup responsibilities.

The Accelerator connects to the database endpoint used by your application. For a managed database, plan the database protocol, network access, credentials, and connection security together. The database continues to be operated through its existing service. Reference designs help you plan the application and acceleration tiers in your environment.

Look for recurring reads and database demand that matter to your application or budget. Evaluate query reuse, the mix of reads and writes, data-change patterns, response times, and throughput under representative traffic. The result should show both how the application behaves and how much work reaches the database. Use Performance Lab.

The architecture hub includes starting designs for customer-managed CMS, CRM, ERP, finance, and master data applications. These show where acceleration fits and which layer owns each responsibility. Use your application’s actual database connection and workload to turn a design into a deployment plan. Explore the workload designs.

The Accelerator keeps reusable query results in memory. When a read is eligible to use a valid cached result, it can be answered without repeating that work on the database. Reads that need the database continue along the database connection path. See how acceleration works.

Change data capture follows committed changes from the database. EngineGrids uses row identities, predicates and dependencies to maintain cached rows and invalidate affected query results. CDC interruptions trigger bypass and resynchronization.

Configure CDC to cover all relevant committed changes, including writes made directly to the database. Review the selected engine’s replication permissions, source coverage and lag. Plan CDC access.

The database’s transaction and isolation rules remain authoritative. Cache reuse follows the engine’s transaction rules, and relevant reads are protected against obsolete cached results while protected writes remain unresolved. Acceleration does not override the normal snapshot behavior of your database transactions.

Read caching does not require queued writes. Select write scope according to the engine and the application’s native response requirements. MySQL and MariaDB writes wait for the actual database response. Review write behavior.

For eligible queued autocommit writes, success acknowledges acceptance into memory before database execution completes. That queue is not durable or replicated, so accepted writes can be lost if the process or host fails. Operations requiring database-generated values wait for the native response.

Write behavior is engine-specific. MySQL and MariaDB preserve actual database write responses. Other adapters can queue eligible single-statement autocommit operations while forwarding transactions and operations that need database-generated results. Review write behavior.

Each instance begins in bypass, forwarding requests while filling its local cache. The default warm-up interval is 120 seconds from operational forwarding. After the configured interval, valid eligible reads can use cached results. Review cache settings.

EngineGrids is available for cloud and on-premises deployments, including VMware and Nutanix environments, and as installable software in customer-managed environments. The Accelerator runs on customer-controlled Linux servers between your application services and database. Choose network access and capacity around your environment and workload. See the deployment overview.

Have the Accelerator packages, an authorized Linux or SSH account, the database endpoint, application credentials, CDC prerequisites and TLS files. Read the setup checklist.

accel_setup provides guided terminal menus for database connections, TLS, CDC, cache memory, warm-up, visibility and acceleration scope. Review masked settings and choose Save or Discard. See the setup steps.

Save and validate the configuration, then explicitly start the Accelerator service. Packaged installations use systemctl; local instances use accel start. Saving configuration does not automatically restart traffic. Follow the start and connection steps.

Start with a single instance, or place independent instances behind an external TCP load balancer. Each instance has its own cache, CDC consumer and sessions. Plan multiple instances.

Each instance consumes database changes through its CDC connection and maintains its own local cache. An external load balancer routes connections. Configuration can be copied with export and import, then reviewed for the destination instance. Review instance operations.

Install and configure the new instance, give it the required CDC identity and permissions, and verify TLS and database connectivity. Review listener ports and local file paths, then configure your external load balancer and warm the local cache. Plan another instance.

Performance Lab helps you plan and run an evaluation with your workload. Compare a direct database path with the same workload through EngineGrids, then review application behavior and database demand. Plan your evaluation.

Choose a representative workload, a cloud test environment, access to database performance measures, and clear success criteria. Plan repeatable conditions before comparing the direct and accelerated paths. Start with the Lab requirements and setup guidance, then use the Accelerator Setup Guide.

Use the same workload and resources for both paths. Establish the direct-database baseline, configure and warm the Accelerator, and repeat the workload through it. Keep measurement periods and units consistent, and record changes in configuration or traffic so you can interpret differences. Review the comparison steps.

Measure application response times, throughput, connection errors, and workload completion. Compare database CPU and statement or execution counts, along with available memory and I/O measures. Record Accelerator resource use too, so a reduction in database work is considered alongside the whole deployment. Understand your results.

The current results show database CPU reduction and cache hit rates for Accelerator 1.0.2 across six engines. Performance Lab helps you evaluate your own workload and deployment. Explore benchmark results.

The outcome depends on query reuse, read and write patterns, connection behavior, resources, and the way the application uses its database. Compare application performance and database demand together: less database work and higher application throughput are different measurements. Set success criteria that reflect your own workload and business goals.

Review performance and database-demand changes, size a proposed deployment, and compare infrastructure, licensing, Accelerator, and operating costs. Then plan rollout and purchasing with your team or partner. You can discuss your results with EngineGrids and review the buying process.

Application-facing, database-facing and CDC TLS are configured independently. Prepare certificate and trust files for the service account. Remote administration uses your existing SSH service with host-key verification. Review connection security.

Use accel and accel_setup locally through operating-system permissions or remotely through SSH. Install the utilities package on a management workstation and retain the authoritative settings on the managed server. Read the remote administration guide.

Applications authenticate using their existing database credentials. New sessions are validated with the database. Configure a separate CDC account with the selected engine’s required replication and metadata permissions. Review accounts and CDC.

Cached results and eligible queued writes remain in instance memory. SQLite stores configuration and bounded error logs. Exported configuration includes secrets but excludes cached results, queued writes and live CDC progress. Review state and storage.

An external load balancer can route new connections to available instances. Failed sessions reconnect; caches refill after restart. In-memory queued writes that have not reached the database can be lost. Review instance operations.

The database remains responsible for durable data, database availability, backup and recovery. Accelerator instances have their own routing and lifecycle responsibilities. Review deployment layouts.

The queue is memory-only and has no recovery journal or replay after a process failure. Allow queued work to drain before planned stops and reconcile application outcomes with the database after a failure. Review queue operations.

Use accel to observe cache hits and misses, CDC status and lag, protocol traffic, cache occupancy and uptime. Review runtime/error logs and export OpenTelemetry metrics for ongoing monitoring. Open the monitoring guide.

Route new connections away from an instance, allow work to finish and verify queue drain. Review and check settings before an explicit restart. Startup bypass forwards requests while the cache warms, and CDC loss triggers bypass until coherence is restored. Plan maintenance.

Export the SQLite configuration and securely preserve referenced certificate and key files. Package upgrades retain instance settings; restart explicitly afterward. Keep database backup and recovery procedures. Review upgrade guidance.

Yes. The free trial lasts 30 days. Evaluate EngineGrids Accelerator with your workloads, on your own or with your partner. Use the evaluation to measure value and plan the deployment and purchasing route. Start a trial conversation.

Plan paid use of the deployment you have already evaluated. Review the offer with EngineGrids and your partner, and continue through the purchase path for that installation. Discuss continuing your current trial.

Pricing depends on the version, deployment size, and actual offer for your organization. Review the applicable offer when planning a purchase. Use your measured deployment needs and include infrastructure and services in the overall budget. Find your purchasing route.

Listings for AWS Marketplace, Microsoft Marketplace, Google Cloud Marketplace, Oracle Marketplace and IBM Marketplace are coming soon. Contact EngineGrids or your partner about installable software for your cloud or on-premises environment. Explore purchasing routes.

Yes. You can work with EngineGrids and your partner on a private offer during your evaluation. Bring your deployment needs, purchasing requirements, and evaluation results to the conversation. Discuss a private offer.

Yes. Introduce EngineGrids to the provider you already work with. Your partner can help coordinate evaluation, deployment, services, and the purchasing path for your cloud, on-premises, or installable software deployment. Explore partner purchasing.

Open the offer link shared by EngineGrids or your partner and review it for your organization and intended deployment. Coordinate the next steps with the team that supplied the offer. If you are already running a trial, include that installation in the purchasing discussion.

Bring your database and application context, evaluation results, expected deployment size, preferred deployment and purchasing route, and partner contact if applicable. Identify the people responsible for procurement and ongoing operation so the software purchase and services plan fit together. Review the buying options.

Your managed service provider is the primary contact for setup, routine operation, and day-to-day support. Start with its support portal or service desk. If you need help identifying the right provider contact, use the provider inquiry route.

EngineGrids provides direct Tier 3 support for engineering issues. Your provider can help coordinate deployment context, investigation, and recovery with the engineering team. Use the engineering inquiry route when that support is needed.

Describe the affected application and database, when the issue occurred, recent changes, and what you expected to happen. Include useful deployment context without passwords, access tokens, or sensitive customer records. The troubleshooting guide helps you prepare the discussion.

Use the Setup Guide for package installation, terminal configuration, database and CDC access, cache settings and application connections. Use the Administrator Guide for accel, SSH administration, monitoring, backup and maintenance.

Transparent read acceleration sits in the database connection path. People continue to use the application they already have; administrators configure the Accelerator and update the application’s connection settings. The operating team uses the setup and administration guides.

Resellers can add database acceleration to their offering and help with purchasing. Systems integrators can build evaluation, deployment, and integration engagements. MSPs can provide ongoing monitoring, optimization, and primary customer support, with EngineGrids handling Tier 3 engineering. Explore the partner program.

Use the designs to place the Accelerator in a customer solution and define responsibilities across the application, acceleration, and database tiers. Build a cost-optimization engagement for an existing environment or plan new CMS, CRM, ERP, finance, and master data applications. Start with the Architecture Hub and use Performance Lab to evaluate the customer’s workload.

Tell EngineGrids how you serve customers, the type of partnership you have in mind, and a customer opportunity where acceleration may help. The partner inquiry form starts the conversation about evaluation, deployment, purchasing, and ongoing services.