Apache Superset and Elasticsearch integration guide

How Superset Elasticsearch integration works through SQL

A team that already has logs or documents in Elasticsearch and wants charts in Superset reaches the data through SQL, not through a search interface. Superset connects to Elasticsearch with the elasticsearch-dbapi package, and queries are written in Elasticsearch SQL or OpenSearch SQL syntax. The Superset database catalog lists the connection string `elasticsearch+ which uses HTTPS and the default Elasticsearch port in that example, so the port and host must match your cluster's actual endpoint. This is a query path for dashboards and charts. It does not give Superset the full-text relevance, highlighting or index administration that a dedicated search application provides.

The practical consequence is that every chart depends on how Elasticsearch SQL behaves on your indexes. Before building dashboards, confirm with your Elasticsearch administrator which SQL features your cluster version supports, how fields are mapped (text fields versus keyword fields in particular), and whether the aggregations your charts need return reliable results at your data volume. The Superset documentation's database catalog is the starting point for the driver and connection string, and the exact functions available should be tested against your own indexes instead of assumed from general SQL knowledge. Ask your team to document the supported query patterns before the first dashboard goes live.

The connection uses a user and password in the connection string, so the account behind it deserves the same scrutiny as any analytics service account. Confirm that the Elasticsearch user is read-only, scoped to the indexes the dashboards need, and that its credentials are stored in Superset's configuration rather than in shared notes. Whether TLS verification and role-based access control are available to you depends on your Elasticsearch license tier, so confirm the features in your subscription before relying on them. Keep this integration for analytical charts over data your team already governs, and plan a dedicated search UI for end-user search and investigation work.

What you need before connecting Superset to Elasticsearch

Connecting Superset to Elasticsearch touches three areas: the Superset image and version, the Elasticsearch cluster and its release line, and the account and network path between them. Settle each area before you write a connection string, because most failed connections trace back to one of these prerequisites rather than to the query itself.

Superset version and install path

Confirm which Superset release you run and how it is installed, since the image build determines whether the driver can be added. Superset 6.1.0 is the release line described in the current upgrade and Kubernetes documentation, and PyPI and Docker-based installs both need the driver baked into the image rather than installed into a running container. Record the exact version so that any later upgrade can be tested against the same driver. Check the Superset docs for the install method your team uses before planning the image build.

The elasticsearch-dbapi package in the image

Superset needs the elasticsearch-dbapi package installed in its own Python environment, and the Superset database catalog lists it as the driver for Elasticsearch. Add it to the custom image or build step so every web and worker container gets the same package. Pin the version in your build file, and record it alongside the Superset version so that a rebuild does not silently change the driver. Confirm with the driver maintainers which Elasticsearch release lines the package supports before you pin it.

A dedicated read-only Elasticsearch user

Create a separate Elasticsearch user for Superset, with a role that grants read access only to the indexes and data streams you intend to chart. Do not reuse an administrator or ingestion account, because the connection string stores credentials in the Superset metadata database. Elasticsearch security features such as role-based access control are available in the free Basic tier, so the restriction can be enforced by the cluster. Document which index patterns the role covers so that reviewers can test it.

HTTPS on the Elasticsearch endpoint

The database catalog connection string uses the elasticsearch+https scheme, so the cluster endpoint must serve TLS that Superset can validate. Confirm which CA certificate your cluster uses and whether Superset's trust store includes it, especially for internal certificate authorities. Plaintext HTTP is not part of the documented pattern for this driver, so treat any requirement to use it as a question for the driver maintainers and your security team before go-live.

Network path and port 9243

The documented connection string targets port 9243, which is a placeholder pattern rather than a fixed port for every cluster. Ask your Elasticsearch team which port and hostname the cluster exposes, and confirm that firewalls and security groups allow traffic from the Superset web and worker nodes. Test the path from the actual containers, because a route that works from a laptop may not work from a Kubernetes pod or a restricted subnet.

Elasticsearch release line and end-of-life dates

Identify whether your cluster runs the 9.x or 8.x line, since current releases are published on both and each has its own support window. Check the Elastic end-of-life page for the end of maintenance date for your version, and plan an upgrade before it if the connection will run for years. Ask the driver maintainers to confirm compatibility with that same release line, because a driver tested on one line may not match query behavior on another.

Configuring the Elasticsearch connection in Superset

This sequence takes Superset from a standard image to a non-admin user charting one Elasticsearch index through a read-only account. Each step ends with a check, so you know the connection and the access model work before you build dashboards on top of them.

Build the Superset image with the driver
Your platform team adds the elasticsearch-dbapi package to a custom Superset image, since the driver is not bundled and must be installed into the same environment that runs the web server and any workers. Build the image from your pinned base version, then deploy it to staging rather than production. Confirm the package is present by opening a shell in the running container and importing the driver module, and check that the Superset database connection dialog lists Elasticsearch as an option. The database catalog in the Superset documentation is the reference for the package name and the connection format, so confirm both against your Superset version before building.
Create a read-only Elasticsearch role
Your Elasticsearch administrator creates a dedicated role that grants read privileges only on the specific indexes or index patterns the dashboards need, and no cluster-level or write privileges. Create a separate user for Superset and assign only this role. Check the security features available on your Elasticsearch license tier before you design this step, because field- and document-level security are paid features in Elastic's subscription tiers, and you should confirm what your subscription includes. The output is a service user whose credentials work for one test index and are rejected for any other index in a direct query.
Add the database connection in Superset
A Superset administrator opens the database connection form and enters the connection string using the Elasticsearch format from the Superset database catalog, with the service user's credentials and your cluster host. Use TLS, because the documented string uses the https scheme on port 9243 in the example, and confirm the port that your cluster actually exposes. Store the password through your secrets handling rather than in a shared document. Save the connection, and do not enable options for DDL or DML if the form offers them, because the account should only read.
Test the connection from the form
Use the connection test in the database dialog before saving, then save and confirm the database appears in the connection list. A successful test shows the connection opening with the service user. If the test fails, check the host, port, TLS settings and the user's index privileges in that order, since a privilege problem often looks like a generic connection error. The check is complete when the test returns a success message and the database entry shows the expected name.
Create a dataset from one index
Open the SQL Lab or dataset creation flow, select the Elasticsearch database, and create a dataset from one index that the read-only role can see. Write the query in Elasticsearch SQL syntax, because the dialect differs from standard SQL for functions and date handling, and keep the first query narrow with a time filter and a row limit. The check is a dataset preview that returns rows whose fields and values match what you see when you query the same index directly in Elasticsearch, with no fields missing.
Chart the dataset under a non-admin account
Create a simple chart and a small dashboard from the dataset, then sign in as a non-admin Superset user who has been granted access to that dataset and dashboard only. Render the chart and confirm the rows match the admin view. Also confirm the non-admin user cannot see other databases or datasets, and that the chart fails when pointed at an index the service role cannot read. The sequence is complete when the chart renders for the non-admin account and the restricted index is refused.

What Elasticsearch SQL can and cannot chart

Treat Elasticsearch SQL as a different query dialect, not a drop-in replacement for a relational warehouse. Before a BI team builds dashboards on an index, it should confirm which aggregations, filters and functions the Elasticsearch SQL version in its cluster supports, because the answer depends on the field types in each index. The most common surprise is the text versus keyword distinction. Fields mapped as text are analyzed for full-text search, so filtering, grouping or sorting on them often fails or returns tokenized values. Charts that group by a dimension should normally rely on keyword fields, or on multi-fields that expose a keyword sub-field. Check the mapping of every field a chart uses, not just the index name, and confirm with the Elasticsearch SQL documentation for your version how each type behaves.

Joins and cross-index queries deserve the same scrutiny. Relational joins between indexes are limited or unavailable in Elasticsearch SQL, so any dashboard that combines two sources usually needs the data denormalized at ingest, a transform, or a separate analytical store. Test each planned chart against a representative index, including nested fields, date math and any function a metric depends on. Result size is the second risk. Superset expects a bounded result set it can render and cache. Charts that return large raw row sets, or that rely on high-cardinality grouping, can slow the browser, time out in the query layer and load the cluster heavily. Set row limits in Superset, prefer pre-aggregated indexes for dashboards, and ask the team that runs the cluster to confirm query limits and circuit breaker settings before the dashboards go live.

How Elasticsearch indexes, fields and roles map to Superset datasets

This table shows which parts of an Elasticsearch-to-Superset mapping are fixed by how the index is designed and which are chosen in Superset. Read the first column to find the object, then check who decides it and what to confirm before building charts.

Element	Decided by	What to confirm before building charts	Where it usually goes wrong
Index name to dataset	Index design (naming and aliases), then Superset dataset setup	Whether the query should target a concrete index, a wildcard pattern or an alias that stays stable across rollovers	Dashboards break when rollover creates new backing indexes and the chart points at an old name
Document fields to columns	Index mapping (field types), then Superset column settings	The mapped type of each field the chart uses, including whether text fields have a keyword subfield for aggregation	Text fields that are analyzed cannot be grouped or summed as expected, so charts return odd or empty results
Date fields to time column	Index mapping (date type and format), then the Superset time column choice	The date format and time zone stored in the index, and whether the field is the event time or an ingest time	Mixed date formats across indexes shift counts by day or hide recent documents
Numeric and keyword fields to metrics and filters	Index mapping, then Superset metric definitions	Which numeric fields are stored as numbers rather than strings, and which keyword fields hold stable values for filters	String-stored numbers produce errors or incorrect sums when used as metrics
Elasticsearch roles and index privileges to Superset roles	Elasticsearch security model, then Superset roles and data access rules	Which indexes and fields the connecting user can read, and whether each Superset role maps to a separate Elasticsearch user	A shared service account gives every Superset user the same visibility, so Superset roles alone do not limit data access
Document-level and field-level restrictions	Elasticsearch subscription tier, then Superset data access configuration	Whether your Elasticsearch license tier includes field- or document-level security before you rely on it	Teams assume Superset filters enforce row limits that were never set in the index
Index schema changes	Index owners, then the Superset dataset definition	Who is notified when a field is renamed or retyped, and who updates the Superset dataset	Charts silently drop columns after a mapping change with no alert to the dashboard owner

Securing the Superset to Elasticsearch connection

A Superset connection to Elasticsearch is only as safe as the account, transport and permissions behind it. The cards below cover the decisions to make before the first chart is built, from the database user to the limits placed on what analysts can create and retrieve.

Create a dedicated read-only user

Give Superset its own Elasticsearch account instead of reusing an administrator or a person's login. Grant read access only to the index patterns the dashboards need, and nothing that allows index creation, deletion or mapping changes. Confirm with your team which indexes contain sensitive fields before the role is written, because a broad index grant exposes every document in that index to every Superset user who can query it.

Verify the TLS endpoint

The connection string the Superset database catalog shows for Elasticsearch uses HTTPS on port 9243, so credentials travel encrypted only if the client actually checks the server certificate. Confirm that the certificate chains to a CA your Superset workers trust, that its hostname matches the endpoint, and that no setting turns verification off. Test the connection from the Superset host itself, since a successful browser login proves little about the worker's trust store.

Keep the password out of the URI

A connection string with an embedded password ends up in the metadata database, in logs and in screenshots of database settings. Where your Superset version lets you supply the password separately, such as through the connection form or a secret mechanism your deployment already uses, move it there and restrict who can read it. Check the configuration documentation for your release, since handling of database secrets has changed across versions, and test that rotating the password does not break existing charts.

Restrict who can add databases

Any user who can create a database connection can point Superset at a host of their choosing and reuse whatever credentials they enter. Limit database creation and editing to a small admin role, and review which roles hold the permissions that allow it. Connections that reach Elasticsearch should be created by platform staff, with the analyst role limited to querying the connections already approved.

Cap result size and query time

Elasticsearch SQL returns result sets that can be large, and a dashboard refresh on a wide index can load a lot of documents into the Superset worker. Set row limits in Superset for SQL Lab and charts, and ask your team to confirm the query timeout and result cap behavior for the driver version you run. Keep limits in place for exports as well, because a permitted export is a common path for bulk data leaving the system.

Confirm your Elastic subscription tier

Field-level security, document-level security and single sign-on for Elasticsearch are paid features in Elastic's self-managed subscriptions, and the free tier does not include them. Without field- or document-level security, the Superset account can read every field and document in the indexes it is granted. Confirm your tier with Elastic and the feature list for your version before you rely on any of these controls, and document the result in your access review.

Licensing and version choices that affect the connection

Before you write a connection string, decide which Elasticsearch distribution your organization is allowed to run, because that decision determines which SQL dialect and driver you chart against. Elasticsearch and Kibana source code is available under three licenses: the Elastic License 2.0 (the default distribution), SSPL 1.0 and AGPLv3. Elastic says the default distribution has been under the Elastic License 2.0 since 2021 and that it added AGPLv3 in September 2024, before the 8.16 release, to offer an OSI-approved open source option. The Elastic License 2.0 and SSPL are not OSI-approved open source licenses, so any open source requirement in your policy has to be checked against the AGPLv3 option. Confirm the license terms with your legal team and read Elastic's licensing FAQ before you commit to a distribution.

Version lines also matter. Elastic currently lists 9.x and 8.x release lines, and its end-of-life dates differ by line, so a cluster you build today may have a shorter maintenance window than you expect. Check the Elastic product end of life dates for the line you plan to run, and confirm with your Elastic contact which features in your Superset charts depend on the tier you hold. Security features such as single sign-on and field- or document-level security sit in paid tiers, so a dashboard that assumes them will fail on a Basic cluster.

If your organization must use an open source search engine that is wire-compatible with the Elasticsearch 7.10 API, OpenSearch is the other option to evaluate. OpenSearch is a fork of open source Elasticsearch 7.10 with OpenSearch Dashboards derived from Kibana 7.10.2, and it uses OpenSearch SQL rather than Elasticsearch SQL. The Superset catalog entry covers both dialects, so the query you write in Superset must match the engine behind the connection. Confirm which engine and version your cluster runs, then match the driver and SQL dialect to that engine before you build any chart.

Common Elasticsearch connection and chart failures

Why does the Elasticsearch connection fail with the default port in Superset?

The most common cause is a scheme or port that does not match the cluster. The catalog string for Elasticsearch uses elasticsearch+ and port 9243, which is the Elastic Cloud default, so a self-managed cluster on port 9200 with plain HTTP needs the scheme and port changed to match its listener. Check the http.port` setting and whether TLS is enabled on the HTTP layer before editing the URI. Mixing an HTTPS scheme with an HTTP listener, or the reverse, produces connection errors that look like authentication failures. Confirm the exact listener with your cluster administrator, then test the URI from the Superset host, not from your laptop, because firewall rules often differ between the two.

How do I fix certificate trust errors when Superset connects to Elasticsearch over HTTPS?

A certificate trust failure means the Superset container does not trust the certificate authority that signed the cluster's HTTP certificate. The fix is to add your internal CA certificate to the trust store used by the Superset image or the Python process, rather than disabling verification in the connection settings. Turning verification off may get a connection working, but it removes protection against a spoofed endpoint and will fail any security review. Ask your platform team which CA issued the Elasticsearch HTTP certificate, whether the certificate includes the hostname Superset uses, and whether the chain includes intermediates. Rebuild the image with the CA added and retest from inside the Superset worker, since the web container may trust a different store.

Why do numeric or date fields show as strings in Superset charts?

Superset reads the types that the Elasticsearch SQL layer returns, and a field mapped as keyword or text will come back as a string even when its values look like numbers or timestamps. Dynamic mapping can also assign different types across indexes that share a pattern, so one index may return a date while another returns a string. Check the mapping with the index mapping API before you build charts, and cast the field in your query where needed. Fix the mapping at the source when you can, because a mapping change usually requires a reindex and a planned data owner decision. Document which index names your datasets point to so that a new index with a different mapping does not silently break existing charts.

Why do Elasticsearch dashboard queries time out on large indexes?

Timeouts usually come from queries that scan many documents or aggregate high-cardinality fields without a time filter. Superset sends the SQL you define through charts and filters, so every unfiltered chart can trigger a full scan across the index pattern. Add a time range filter on a date field in each dataset, keep aggregations to fields with bounded cardinality, and avoid SELECT * style exploration on large indexes. Check the query duration in the Elasticsearch slow log and compare it with the Superset query timeout setting. Raising the timeout only hides the problem for a while, and the reader should confirm with the cluster owner whether heavy dashboards belong on a separate index or a data tier with suitable resources.

Which Elasticsearch SQL queries fail in Superset when OpenSearch is the target?

Elasticsearch SQL and OpenSearch SQL share a common syntax, but they are not identical, so a query written for one engine can fail on the other. OpenSearch is a fork of Elasticsearch 7.10 and is wire-compatible with that version, so functions, keyword handling and error formats added in later Elasticsearch releases may not exist on OpenSearch. Driver behavior for pagination and type mapping can also differ. Keep a short list of queries that you have tested on the exact engine version in production, and rerun that list after any upgrade. Confirm the target engine and version with the team that runs the cluster before writing datasets, because the Superset database entry alone does not show which dialect a given server accepts.

Which Elastic license applies when Superset queries a self-managed cluster?

The license is set by the Elasticsearch distribution you run, not by Superset. Elastic states that its default distribution has been under the Elastic License 2.0 since 2021, and that AGPLv3 was added as an OSI-approved option in September 2024 before the 8.16 release. Elastic's licensing FAQ also says ELv2 and SSPL are not OSI-approved, so teams with an open source requirement should confirm which build they install. Superset itself is Apache-2.0 and has no paid edition. Ask your legal or procurement team to review the Elasticsearch distribution and any subscription tier separately, because security features such as single sign-on and field-level security sit in paid tiers on self-managed installs.

Should I fix Elasticsearch charts in Superset or move to a dedicated search UI?

Keep charting in Superset when the questions are aggregate, time-based and answered through SQL by analysts. Move to a dedicated search UI when users need free-text relevance, document-level browsing, or log-style investigation that does not fit a chart. Before choosing, test three or four real questions from your users in both tools and record which one needs manual SQL workarounds. The cost of a dedicated UI includes its own access model, hosting, upgrades and training, so ask for those components in any quote. An implementation partner can scope either path in writing, but the decision should rest on your users' questions and your data governance rules, not on tool preference.

When a dedicated search UI fits better than Superset

Dedicated search interfaces are built for people who look for specific records and need the engine to rank them. Full-text relevance tuning, fuzzy matching, highlighting of matched terms, and faceted filtering that narrows results as the user types all sit closer to the search layer than to a chart builder. Superset charts aggregate rows, which is a different job from ranking documents by how well they match a query.

Relevance tuning: Scoring, boosting and analyzers are configured for document search, not for aggregated chart queries in Superset.
Faceted navigation: Interactive facets that update result counts on each click fit a search UI better than a dashboard filter bar.
Application search: If end users search your product catalog or content, build that experience in your application or a search-focused front end.
Result inspection: Viewing and comparing individual documents is a search task, not a chart task.
Feature confirmation: Check which relevance and facet features your chosen search tool supports in its current release before you plan around them.

Before you commit, confirm with the team who owns the search use case which features they need and whether an application search front end is already in scope.

What buyers ask before connecting Superset to Elasticsearch

What drives the cost of connecting Superset to Elasticsearch?

The cost is driven by how many indexes and fields the charts need, how cleanly those indexes are mapped, and how much security configuration sits around the connection. Index design and field mapping are usually the largest variable, because Elasticsearch SQL only exposes what the mapping defines and inconsistent field types across indexes add testing work. Driver maintenance, a read-only user, role scoping and testing against a non-production cluster add smaller, recurring effort. Ask any partner for a quote built from a written scope that lists indexes, charts, roles and test environments, since no fixed price applies across different clusters.

How long does an Elasticsearch to Superset connection take to build?

Duration depends mainly on how many indexes are in scope and how many charts and dashboards depend on them. A single index with a few stable fields is a much smaller job than a set of time-based indexes with mixed mappings and row-level access requirements. Plan separate time for validating each chart's query against real data and for reviewing results with the index owners. DeployOpen does not publish durations; the written scope is where the timeline is agreed before work starts.

What does our team need to provide for the connection work?

Your team needs to name index owners who can confirm field meanings, retention rules and which indexes contain sensitive data. You also need a read-only Elasticsearch user scoped to the indexes in scope, a test environment or staging cluster that matches production mappings, and a sample of the queries analysts expect to run. Access to the Superset instance and a decision on who can publish charts are also required. Missing index owners is one of the most common reasons these projects stall.

Can our own team connect Superset to Elasticsearch without a partner?

Yes, a team with Superset administration experience and someone who knows the Elasticsearch mappings can connect a small number of indexes alone. The elasticsearch-dbapi driver is installed into the Superset image and the connection is defined in the database settings, so the mechanics are not the hard part. The harder work is confirming that SQL results are correct, restricting access properly and keeping the driver working through Superset upgrades. Teams without that combination, or with many indexes and strict access rules, often benefit from outside review of the design.

Which Elasticsearch SQL limits will break our dashboards?

Elasticsearch SQL does not support every join, subquery or aggregation pattern that analysts write in a warehouse SQL dialect, and it behaves differently from the OpenSearch SQL syntax the Superset catalog also names. Test each chart against the real indexes before publishing it, and confirm the supported functions for your Elasticsearch version in the Elastic documentation. Dashboards that depend on complex relational logic usually belong in a database built for that workload, not in a search index queried through SQL.

How do we handle Elasticsearch licensing and version support?

Elasticsearch's default distribution is under the Elastic License 2.0, which is not an OSI-approved open source license, and AGPLv3 was added as an OSI-approved option before the 8.16 release. Confirm which license and subscription tier your deployment uses, because some security features such as single sign-on and field- or document-level security sit in paid tiers. Also check the Elastic end-of-life dates for your version line, since 8.x maintenance ends on January 15, 2027 and 9.x on October 15, 2027, before you finalize the design.

When should we use a dedicated search UI instead of Superset?

Choose a dedicated search UI when users need free-text search, relevance tuning, document browsing or log investigation rather than aggregated charts. Superset is designed for SQL-based exploration and dashboards, so it fits metrics, counts and trends over indexed data. For investigation workflows, a tool built around Elasticsearch or OpenSearch queries often fits better, and the choice should be tested with the people who will use it daily.

What access controls should we set before exposing Elasticsearch data in Superset?

Create a dedicated read-only Elasticsearch user for Superset and grant it only the indexes and fields the dashboards need. Store the connection credentials in the Superset database settings rather than in chart definitions, and test that Superset roles cannot reach data beyond their assignment. Confirm which security features your Elasticsearch subscription includes, since field- and document-level security are not part of every tier. Ask any implementation partner to document the access model and test it before go-live.

How DeployOpen scopes an Elasticsearch connection in Superset

DeployOpen plans, implements, hardens and documents self-hosted Superset connections to Elasticsearch inside your own infrastructure, so the connection, the metadata database, the caching layer and any worker processes run in the cloud accounts, data centers or restricted networks you control. For this topic, the scoping work starts with decisions that are easy to skip: which Elasticsearch deployment will be queried (a self-managed cluster, an ECK-managed cluster or a managed service), which Elasticsearch release line the cluster runs, which elasticsearch+https connection string and service account Superset will use, and whether the query user can read only the indexes the business needs. Each decision is recorded in a written scope before build work begins, along with the datasets, dashboards and access roles that will be delivered.

Most engagements are fixed-scope. The written scope names the deliverables (the Superset database connection, the driver installed in the image, the read-only Elasticsearch role, the datasets, the test plan, the runbook and the handover notes), the environments included, and the acceptance checks each deliverable must pass. Scope drivers specific to this integration include the number of indexes and fields to chart, whether Elasticsearch SQL or OpenSearch SQL syntax is needed, how many Elasticsearch environments sit behind Superset, and whether certificate trust, network paths and identity mapping need separate work. Ask any partner to show how each of these items is priced and what changes trigger a scope amendment. DeployOpen does not publish a price list, so the quote follows from that written scope.

Support after go-live is available as a retainer. Typical retainer work for this integration includes testing the connection after Superset or Elasticsearch upgrades, checking the Elastic release lines and end-of-life dates your cluster depends on, reviewing query behavior as indexes grow, and keeping the documentation current. Confirm before signing what the retainer covers, how response times are defined, and who on your side owns access approvals. DeployOpen is not an official partner or certified provider of Elastic, Apache or any other vendor, and it does not issue audit reports or certifications. Compliance readiness work prepares your systems and evidence for an independent assessor to review.

How DeployOpen delivers Superset and Elasticsearch work

DeployOpen plans, implements and hardens self-hosted Apache Superset inside your own infrastructure, and we connect it to Elasticsearch only after the access model, query limits and data scope are agreed in writing. Each engagement is fixed-scope, so the deliverables, the Superset and Elasticsearch versions in use and the handover items are settled before build work starts.

How we scope

We confirm which Elasticsearch indexes, fields and users the dashboards need before choosing a connection.
We record the Elasticsearch license tier and features your team has, such as TLS and role-based access control.
We agree the written scope, deliverables and timeline with you before any build work begins.

How we build

We install the elasticsearch-dbapi driver in the Superset image and test the connection string against a staging cluster.
We create read-only Elasticsearch roles for Superset, then validate which Elasticsearch SQL queries the dashboards need.
We test chart queries, row limits and dashboard load behavior, and document any queries that must move to a search UI.

How we hand over

We deliver the configuration, the image build steps, the role definitions and the list of supported and unsupported queries.
We document the upgrade steps for Superset and the Elasticsearch driver, including the checks to run in staging first.
We walk your platform and analytics teams through operations, troubleshooting and the open decisions left for your owners.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
We can review Elasticsearch version and end-of-life dates with you so upgrades are planned ahead of support deadlines.
We can re-test dashboards and access rules after Superset or Elasticsearch upgrades, based on the retainer scope agreed.

Apache Superset and Elasticsearch integration