CSV and Excel upload in Apache Superset

Why teams enable CSV and Excel upload in Apache Superset

An analyst holds a spreadsheet of reference data, such as regional sales targets or a product code mapping, and needs it joined to warehouse tables in a dashboard by the end of the week. Superset can create a table from an uploaded CSV or Excel file when upload is enabled for a specific database connection. The uploaded file becomes a table in that database, which Superset can then expose as a dataset for charts and dashboards. For a small, well-understood file, this removes a round trip through a data engineering queue.

The trade-off is that an upload is not private to the person who made it. The new table lives in a database other users may be able to query, and once a chart or dashboard depends on it, the table becomes shared infrastructure with an owner, a schema and a refresh question nobody planned for. Faster ad hoc analysis gains value only when the team knows which database and schema receive uploaded tables, who may upload, and who is responsible when the data is wrong or stale. Those decisions belong in the rollout plan before the feature is switched on, not after the first unexpected table appears.

The exact enablement steps depend on your Superset version and the database engine behind the connection, because upload support and the permissions that control it have changed across releases. Confirm the current setup for your version in the Superset documentation and the release notes before you change any configuration, and test the upload path in a staging instance that mirrors your production database. Ask the vendor or your own platform team which engines in your estate support uploads and how their privileges are granted, since the database account used for uploads needs rights that a read-only analytics account does not have.

Upload options and when each one fits

This table compares the choices a team makes before turning on file uploads: which connections accept them, which schemas they write to, who can upload, and whether tables land in a sandbox or a shared schema. Read each row as a decision point, and treat the most open option as the one that needs the strongest governance.

Decision	Option	When it fits	What it exposes
Database connection	Dedicated analytics connection for uploads only	Teams that want uploads kept away from production reporting sources and from the connection used for dashboards	Uploaded tables can be queried through any dashboard or SQL Lab session that can reach that connection, so the connection's own privileges set the blast radius
Database connection	Existing shared warehouse connection	Small deployments where one connection already serves all analysts and the team accepts that uploads sit beside curated data	Upload writes can land next to certified tables, and a mistaken name can overwrite or confuse trusted data
Target schema	Dedicated sandbox schema with write rights limited to it	Ad hoc analysis where users need a place to load files without touching curated schemas	Users can still create many tables, so storage growth and naming discipline need an owner and a cleanup routine
Target schema	Shared curated schema	Rarely advisable for ad hoc files, though some teams load reference lists that others must join	Analysts' files become sources for production dashboards, which weakens lineage and review
Upload permission	Limited to a small named role	Early rollout, pilot groups, or teams with clear data ownership	Fewer people can create tables, but the role's scope must be checked against each allowed schema
Upload permission	Open to all analysts	Only where the org has already accepted self-service table creation on that connection	Any analyst can introduce data of unknown quality or sensitivity into a warehouse that others query
File source	Internal extracts from approved systems	Reconciliation and reporting work where the file's origin is known	Lower risk of sensitive or malformed content, but personal data in exports still needs controls
File source	Files from email or personal drives	Hard to avoid in some business units, so confirm before allowing	Unknown provenance, possible personal data, and spreadsheet formulas or inconsistent types that distort results

Setting up CSV and Excel upload safely

This sequence turns file upload from an open setting into a controlled path: a known Superset version, one target schema, a role that can only write there, and a tested upload that lands where it should and nowhere else.

Confirm the Superset version and upload behavior
The platform team checks which Superset version is running and reads its release notes before changing any upload setting. Upload behavior changed in 5.0.0, which removed the CSV_UPLOAD_MAX_SIZE setting, moved size limits to the web server, and replaced the per-file-type upload endpoints with new ones and simpler permissions. Any runbook or guide written for an earlier release may describe settings that no longer exist. Done means the team has written down the exact version in use and the upload controls that version expects, checked against the project's UPDATING.md notes.
Choose the target database and schema
The data owner and the platform team agree on one database connection and one dedicated schema where uploaded tables may be created. Avoid pointing uploads at production schemas that other teams query or at schemas that hold source data. Confirm with the database administrator which role has write rights to that schema and whether the metadata for uploaded tables will be kept apart from curated data. Done means a named database and schema are recorded in the change ticket, and the database administrator confirms that the schema holds no tables that uploads could overwrite.
Create a dedicated role for uploads
An administrator creates a Superset role used only for file uploads, granted the upload permission for the chosen connection and no broader data access. Users who need uploads are added to this role deliberately, not through a general analyst role. The role should not carry rights to other databases or to administrative functions. Done means a test user with only this role can see the upload option on the target connection, and a user with the standard analyst role cannot see it. Record who approved each membership.
Enable the upload option on that connection
In the database connection settings, the administrator turns on file upload for the single connection chosen in the earlier step and leaves it off for every other connection. Confirm that the database engine supports uploads in the version of Superset you run, and that the connection's database user has only the privileges needed to create tables in the target schema. Done means the upload option appears for the intended connection, and a database query shows the connection's user cannot write to any other schema.
Set the upload size limit at the web server
Because Superset 5.0.0 no longer reads a size setting for CSV uploads, the limit is enforced by the reverse proxy or web server in front of Superset. The platform team sets a maximum request body size there, sized to the largest file the data owner has approved, and checks the value in the deployed configuration rather than relying on an application setting. Confirm with the team that operates the proxy which setting applies to Superset's upload path, since proxy configuration varies by product. Done means an oversized test file is rejected before it reaches Superset, and the limit is recorded in the runbook.
Test with a small file and an unauthorized user
Upload a small, non-sensitive test CSV and a small Excel file as a user holding the upload role. Confirm the table is created in the intended schema, the column types match the source, and the row count is correct. Then sign in as a user without the upload role and confirm they cannot upload to that connection or write to the table through SQL Lab. Done means both checks pass and the test table is dropped afterward. Repeat this test after every Superset upgrade, since the upload path can change between releases.
Set governance for user-uploaded tables
Decide who owns uploaded tables, how long they persist, and who may delete them. Ask the data owner to name a review cadence and a rule for removing tables that contain sensitive data. Confirm that uploaded tables fall under the same access rules as other data in the schema, including any row level security applied to datasets built on them. Done means a written owner and retention rule exist for the schema, and a sample uploaded table has been checked against the access model before anyone else is granted the upload role.

Governance risks for user-uploaded tables

Uploads give analysts a fast path into your warehouse, and that path skips the review that governs modeled data. The cards below cover the risks that appear once uploaded tables start living next to production data, and the control to design for each one.

Uploads land in shared schemas

If an upload target is a schema that other users or roles can query, a file uploaded for one analysis becomes visible to everyone with read access to that schema. Design a dedicated upload schema with its own grants, separate from curated and production schemas. Verify which schemas appear in the upload target list for each database connection and which roles hold read access to them.

Sensitive data pasted into spreadsheets

Analysts often export personal, financial or health data to a spreadsheet and upload it without checking what the file contains. The upload then copies that data into the warehouse outside its original controls. Set a rule for which data classes may be uploaded and who approves exceptions. Verify that the upload permission is limited to roles that have completed the data handling training your organization requires.

Orphaned tables after staff leave

An uploaded table keeps its owner's name in the metadata, and it stays queryable after that person's account is disabled. Dashboards and saved charts may then depend on a table nobody maintains. Assign an owner group rather than an individual, and set a retention rule that flags unused upload tables for review. Verify that offboarding includes a check of the tables and datasets the departing user created.

Uploads that bypass data modeling

When analysts upload a file that repeats a dimension the data team already models, the organization ends up with two versions of the same metric. Reports then disagree without an obvious cause. Define which subjects must go through the modeled layer and which may stay in the upload schema for exploration. Verify that uploaded datasets are labeled as exploratory in their names and descriptions so readers can tell them apart from certified datasets.

Row level security missing on new tables

Row level security filters apply to the tables and datasets you configure them for, so a new upload table has no filter until someone adds one. A user who sees a restricted region in the source data may then see every row of the upload. Decide before rollout which roles may upload, and test that RLS rules cover upload schemas before any group receives access. Verify this with a test account in each affected role.

Uploads inflate storage and query cost

Each uploaded file creates a table that consumes warehouse storage and may be scanned by every dashboard that references it. Large or repeated uploads can raise compute charges on pay-per-query platforms. Set a row and size expectation for uploads, and limit the upload size at the web server, since Superset 5.0 removed the CSV_UPLOAD_MAX_SIZE setting in favor of that approach. Verify the web server limit and check warehouse billing alerts for the upload schema.

Who owns an uploaded table after the upload

An uploaded CSV or Excel file becomes a physical table in a database you connected to Superset, and that table then has an owner and a lifecycle of its own. Superset creates the table and loads the rows, but it does not decide who may rename, replace, drop or reuse it afterward. Those decisions sit with the database, so before enabling uploads you should record who owns each upload target schema, who is accountable for the data in it, and what happens to a table when the person who uploaded it leaves. Treat the upload as the start of a database object's life, not the end of a user task.

Record the lifecycle decisions as a short policy the data team can point to. Decide who may rename, drop or overwrite an uploaded table, whether users may reuse an existing table name, and how long temporary uploads are kept before cleanup. Decide also how datasets built on an uploaded table are reviewed before a dashboard depends on them. A dataset is a Superset object with its own access rules, so an upload that quietly becomes a dashboard source can outlive its original purpose. Ask your team how it will learn that this has happened, for example through a periodic review of datasets that point at upload schemas, and assign that review to a named role.

Confirm the database-side ownership model for your engine before you write the policy. Find out which account creates the table, whether that account's privileges let the uploading user later alter or drop it, and how grants on new tables are inherited by other roles. These behaviors differ between database engines and between configurations, so verify them in a test database with the exact account Superset uses rather than relying on general assumptions. The result should be a written answer for each upload schema covering the owner, the permitted changes and the review path.

Upload size limits at the web server since Superset 5.0

From Superset 5.0.0, upload size is no longer set by an application setting. The CSV_UPLOAD_MAX_SIZE setting was removed, and size is limited at the web server instead, so the control now sits in the same layer as your reverse proxy, load balancer or ingress. The upload endpoints also changed. The per-file-type endpoints were replaced with new ones, and the permissions that govern uploads were simplified.

Size control moves outward. Set the request body limit in the web server or proxy that fronts Superset, and confirm it applies to the path Superset uses for uploads. A limit set only on an upstream layer may not match the path your users hit.
One key to remove. Delete CSV_UPLOAD_MAX_SIZE from superset_config.py so no one assumes the application enforces a value it no longer reads.
New endpoints. Scripts, proxy rules and allow lists that matched the old per-file-type paths need updating against the 5.0.0 endpoints.
Simpler permissions. Review which roles can upload, since fewer permission entries now cover the feature. Confirm the result by signing in as test users in each role.
Every layer in the path. Kubernetes ingress controllers and cloud load balancers often apply their own body limits, so check each one in the request path.

Test the limit from a non-production account with a file just under and a file just over your chosen threshold, and confirm the rejection message reaches the user.

Before 5.0.0, upload size was controlled inside Superset through the CSV_UPLOAD_MAX_SIZE setting in the configuration file. Teams on these versions set the limit in the application, and the web server layer usually only needed to pass requests through. Upload endpoints were organized per file type, and the permissions attached to each endpoint reflect that structure.

Application-level limit. The limit was enforced by the setting in superset_config.py, so changing it meant a configuration change and a restart of the application.
Per-file-type endpoints. Access rules were written against separate upload paths, so roles were granted upload rights for each file type individually.
Proxy limits still apply. A reverse proxy or ingress can reject a large request before Superset receives it, so a generous application setting does not ensure the upload succeeds.
Record the current value. Note the effective limit and where it is set, since that setting is removed when you upgrade to 5.0.0 or later.

Before planning an upgrade, export the current configuration and list the effective upload limit along with every role that holds upload access.

Limits to confirm in your environment

File upload behavior in Superset depends on the web tier, the database engine, the permission model and the way uploaded tables are read afterward. Each item below is a limit to verify in your own environment, with the place to check it before users depend on it.

Web server and proxy upload limit

Since Superset 5.0.0, the CSV_UPLOAD_MAX_SIZE setting was removed and file size is limited at the web server instead. Check the body size limit in your reverse proxy, load balancer and ingress, not only in Superset, because the smallest limit in the chain decides what users can upload. Test with a file just above your target size in staging so a proxy rejection does not look like a Superset error.

Engines that accept uploads

Upload support is per database connection and per engine, so a database that works for SQL Lab may not accept file uploads. Confirm which of your connected databases allow uploads in the Superset version you run, and check whether the engine's driver and permissions allow the table creation the upload performs. Record the result per database rather than assuming one answer applies to the whole instance.

Permissions after the 5.0.0 change

Superset 5.0.0 replaced the per-file-type upload endpoints with new ones and simpler permissions. Roles built for older releases may grant the wrong upload rights or none at all. Review which roles can upload, which schemas they can write to, and whether upload rights are granted together with SQL Lab access, then verify with a test user from each role.

File types beyond CSV and Excel

Behavior for other formats, such as columnar or delimited text files with other separators, depends on the version and the upload options exposed in your installation. Do not treat a format as supported because the menu shows it. Test each format your users need with representative files, and check the parsing of dates, decimals and encodings against the source data.

Timeouts on large files

Large uploads can exceed the proxy read timeout, the application server worker timeout or the database load time before the table is ready. A timeout can leave a partial table or a failed request that users retry. Measure how long your largest expected file takes end to end in staging, and set the timeouts across the proxy, web workers and database to match that measurement.

Caching and row level security on uploaded tables

Uploaded tables are ordinary datasets once created, so cached query results and row level security filters apply to them. Confirm that cache timeouts do not show stale results after a user replaces an upload, and that RLS rules still reach the new table. Test with two users who should see different rows before you share dashboards built on uploads.

What buyers ask about CSV and Excel upload in Superset

What drives the cost of setting up CSV and Excel upload in Superset?

The cost depends mostly on how many databases will accept uploads, how many schemas and roles need separate rules, and how much testing the change needs before users see it. Enabling the feature is a configuration change, but deciding which tables users may create, where they land, and who can read them takes design work. A fixed-scope quote should list each database, each upload path, each role, the test files used, and the staging environment involved. Ask whether the quote includes documentation for analysts and a handover to your team. Recurring costs are usually limited to reviewing uploaded data and keeping Superset current, which you can plan internally or add as a retainer.

How long does a controlled rollout of file uploads take?

Duration depends on the number of databases, the number of roles that need upload rights, and whether your data owners have already agreed on schema rules. A single database with one upload schema and a small group of analysts is a much smaller task than several databases with separate owners and approval steps. Ask any partner to break the timeline into design, configuration, staging tests with real-format files, and a pilot with a limited group. Confirm with your own change board how long review and approval take, because those steps often set the pace more than the technical work does.

What does our internal team need to provide for an upload project?

Your team needs to provide read and write access to the target databases in a test environment, named schema owners who decide where uploaded tables may live, and decisions on which Superset roles may upload. Sample files are important: provide representative CSV and Excel files with the column layouts, date formats and encodings your analysts actually use, including messy examples. You also need a named approver for the governance rules on uploaded tables, such as retention and cleanup. Without these inputs, the design will rely on assumptions that often need rework during testing.

Can our team enable and govern CSV uploads without outside help?

Yes, a team with Superset administration experience and access to its database and web server settings can often make the change alone. The harder part is the governance work: confirming which databases are safe for uploads, restricting target schemas, deciding who may upload, and planning how uploaded tables are reviewed or removed. Upload size limits are set at the web server, not in a Superset setting, since Superset 5.0.0 removed CSV_UPLOAD_MAX_SIZE, so the change touches infrastructure as well as the application. Teams that lack a second reviewer for role and database permissions may want an outside check on the final configuration.

What does a fixed-scope DeployOpen engagement for uploads cover?

A fixed-scope engagement covers only the items agreed in writing before work starts, such as the list of databases in scope, the upload schemas and roles, the web server upload limit, the test plan, and the handover documents. DeployOpen plans and configures these items in infrastructure you control, tests them with your sample files, and documents the result for your team. It does not cover changes to your warehouse design, data quality remediation of uploaded files, or work outside the agreed list unless the scope is amended. Ask for the acceptance criteria in the written scope so both sides know when the work is complete.

Which security risks should a CISO check before allowing file uploads?

The main risks are users loading sensitive data into schemas that other teams can read, uploads reaching production databases by mistake, and uncontrolled growth of tables that nobody owns. Check which databases are enabled for uploads, whether target schemas are separated from production reporting schemas, and which roles can upload and query the results. Also confirm how file content is validated and how long uploaded tables are kept. Review these controls with your data owners and security team before rollout, and confirm the specifics against the Superset documentation for your installed version.

How do we check that uploads work correctly after the change?

Test with the sample files your analysts use, including the difficult ones: mixed date formats, unusual delimiters, long text fields, duplicate headers and large row counts. Verify that each permitted role can upload to the allowed schema and that other roles and databases are refused. Check that uploaded tables appear with the expected column types, that the web server rejects files above the agreed limit, and that the audit trail records who uploaded what. Repeat the tests after every Superset upgrade, since upload endpoints and permissions changed in 5.0.0 and may change again.

How DeployOpen scopes and delivers upload governance for Superset

DeployOpen plans and delivers CSV and Excel upload governance as part of a self-hosted Superset deployment in infrastructure you control. The work starts with written decisions about which databases and schemas accept uploads, who may use them, and how user-created tables are owned, reviewed and retired.

How we scope

We list every database connection and decide which, if any, may accept user file uploads.
We agree the target schemas, naming rules and ownership of uploaded tables in writing.
We confirm the web server upload limit, the roles allowed to upload, and who approves exceptions.

How we build

We configure upload-enabled connections, schema restrictions and role permissions in a staging environment first.
We set the upload size limit at the web server layer, since Superset 5.0 no longer uses CSV_UPLOAD_MAX_SIZE.
We test uploads with representative files, including oversized files, malformed Excel sheets and duplicate table names.

How we hand over

You receive the written upload policy, the permission matrix and the configuration changes applied to your environment.
We document the cleanup procedure for user-uploaded tables, including who reviews them and how they are removed.
Your team walks through a live upload, a rejected upload and an audit of the uploads log before go-live.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and re-checks of upload permissions after Superset upgrades are available as a retainer.
We recommend reviewing UPDATING.md before each Superset upgrade, since upload endpoints and permissions have changed between releases.

Uploading CSV and Excel files to Apache Superset