A Database Tab Quietly Appeared in ChatGPT Sites, No Announcement Made

A Database tab has been added to ChatGPT Sites, OpenAI's website-building feature. It sits in the site detail screen, third in line after Settings and Analytics. OpenAI hasn't announced this tab. There's no sentence describing it in ChatGPT's release notes, the help center documentation, or the official Sites guide. The earliest screenshot confirmed so far was captured on August 17, meaning the tab was already live by at least that date.

Something moved on the documentation side around the same time, too. Comparing an August 10 snapshot preserved on the Wayback Machine with the current Sites documentation shows that a table listing storage limits for sites was added in between: D1 at 10GB, R2 with no fixed limit. Even as OpenAI revised the section covering data handling, it left out any mention of the tab that actually displays that data.

What ChatGPT Sites actually is

Sites is a feature that lets users build websites and lightweight apps inside ChatGPT and have them hosted automatically. It first opened as a preview on June 2 for Business and Enterprise workspaces using Codex, then rolled out as a public beta in ChatGPT's release notes on July 9. OpenAI describes it as a way to turn work or ideas into interactive websites without leaving ChatGPT. The intended use cases are smaller-scale pages: dashboards, application forms, internal trackers, calculators.

A site built this way gets an address in the form sitename.username.chatgpt.site. If you already own a domain, you can point its DNS records at the site, but Sites itself does not purchase or register domains on your behalf. As of launch, custom domains are not available for Enterprise workspaces.

The data-handling side is the backdrop to this story. Official documentation describes two kinds of storage attached to a site. D1 is a relational database for table-shaped data meant to persist, and R2 is object storage for raw files. The names D1 and R2 match products Cloudflare sells under the same names — a database and an object storage service, respectively. OpenAI's documentation uses only the names and doesn't specify whose infrastructure is behind them.

Storage	What it holds	Limit
D1	Table-shaped data such as applicant lists, status values, logs	10GB per site
R2	Raw files such as photos, PDFs, videos	No fixed limit

The two storage types split responsibilities. Upload a photo, and the original file goes to R2, while D1 gets a single row recording where the file lives (object_key), along with its format, size, and creation timestamp. That earlier 1272167 figure is exactly that row.

What the Database tab actually shows

The screen title reads Database, with the description beneath it: "View the data used by your live site." Connection status and a table list sit on the left; the columns and rows of whichever table is selected appear on the right.

Screen element	What it shows
Connected indicator	Whether the site is linked to a database
TABLES list	Names of every table attached to this site
Table area	Column names and actual rows. Scrolls horizontally if there are many columns
Showing 1–6	Which range of rows the current view covers
← → buttons	Navigate to the next or previous batch of rows
Refresh button	Re-fetches the data as it stands right now

The confirmed screen showed two tables. One had seven columns — id, title, owner, status, note, created_at, updated_at — with six rows. The other had columns id, title, object_key, content_type, size_bytes, created_at, containing metadata for a single photo. Even with a small row count, the Showing 1–6 label and pagination buttons remain attached below the table.

Read-only, for now

The confirmed screens have no button for editing cells or adding and removing rows. To change a value, you still have to ask ChatGPT to modify the site's code, or enter data through a form built into the site. At this stage, it functions less like a database management tool and more like a viewer for checking live data.

Still, something has changed. Previously, building a form or gallery with Sites meant guessing at what shape the underlying data actually took, based only on what appeared on screen as output. Now you can look directly at the tables and columns before deciding what to ask for next.

How to build one

Where to start. On the web, select Work. In the desktop app, choose ChatGPT and then go into Work, or select Codex directly. Use the Create button in the top right of the list screen to start a new site; for an existing one, click its name in the sidebar's Sites list, or select Settings from the "…" menu, to reach the detail screen. The Database tab sits at the top of that detail screen.

Step by step.

The first five steps follow the order laid out in the help center documentation. The remaining four cover checking the newly added tab.

1. Describe the website you want to build in a chat with ChatGPT. Including the word "website" in your prompt, or mentioning @Sites, reliably routes the request into a Sites task.
2. Provide the materials you want to use. The documentation lists five categories: content, files, data, links, and constraints. Supply logo files, exact copy, reference page URLs, and requirements like "must fit on one mobile screen" all at once at this stage. Skipping this and fixing things one at a time later means more back-and-forth.
3. If you need to store data, list out what should be saved. Something like "an application page that stores applicant name, email, and submission time in a database" prompts ChatGPT to build a matching table and attach it to the site.
4. Review the preview ChatGPT generates. Nobody else can see it at this stage yet.
5. Keep requesting edits until it's ready to share or publish. Adjust wording, colors, fields, and behavior through conversation.
6. Deploy. Once deployment finishes, you get an address at name.username.chatgpt.site.
7. Set the access level: owner and admins only, specific people or groups, the entire workspace, or the entire internet. The last option requires an administrator to enable it first for Enterprise workspaces.
8. Actually put data into the site. Fill out and submit a form, or upload a photo.
9. Open the Database tab on the site detail screen. Select a table on the left and check whether the value you just entered shows up as a row. If it doesn't, click Refresh in the top right.

Who can use it. Free and Go plans cannot use it. Business and Enterprise got early access via the June 2 Codex preview; Pro, Pro Lite, and Edu were added in the July 9 public beta, with Plus following a few days later. At launch, the EEA (European Economic Area), Switzerland, and the UK were excluded, but OpenAI's developer account announced on July 20 that Plus and Pro users in those regions had been given access. South Korea was never on the excluded list.

Item	Condition
Plan	Any paid plan except Free and Go (public beta)
Region	EEA, Switzerland, UK excluded at launch → opened to Plus/Pro users in those regions on July 20
Access point	ChatGPT web Work · desktop app Work or Codex
Enterprise workspace	Admin grants creation and publishing permissions separately
Visitor verification	ChatGPT account login can be attached to a site
Custom domain	Connect an existing domain via DNS; unavailable for Enterprise workspaces at launch

What you can try. Build an internal event sign-up page, and every submission adds a row to a D1 table, letting you instantly count applicants from the Database tab. Build a team photo archive, and while the originals go to R2, filenames, sizes, and upload times land in D1, letting you see in table form which files are the heaviest. Attach ChatGPT login to a site, and visitor emails and names come through as oai-authenticated-user-email and oai-authenticated-user-full-name headers, so you can even record who submitted what in your tables.

How to edit, share, and take down

Editing is something you'll do more often than building from scratch. Here's the process straight from the help center documentation.

Editing. Reopen the conversation where you originally built the site, or click Sites in the sidebar, find the site in the list, and click the edit icon. Once the composer opens, describe what you want changed — the documentation gives copy, layout, data, styling, links, forms, and interactive behavior as examples. Review the updated preview and keep describing further changes as needed.

Saving and deploying are separate steps. To review a change without touching the live site, save a version first, and only deploy after review is complete. Treating these as one step means unreviewed screens can go live directly.

Changing sharing scope. From the preview, click Share and choose from "who has access": owner and workspace admins / selected active users or groups / everyone in the workspace / everyone on the internet. In Enterprise workspaces, the last option only appears once an admin has enabled public publishing.

Attaching a domain. Four steps.

1. Open site settings and click "Add domain."
2. Enter a root domain or subdomain.
3. Copy the DNS records and values Sites provides and add them exactly as shown at your domain provider (Gabia, Whois, Cloudflare, etc.).
4. Wait a few minutes, then refresh the domain status in Sites.

Taking down and deleting. Open Sites in the sidebar and click delete site. The confirmation dialog requires you to manually type the site's slug before permanent deletion is enabled. If you just want to stop public access rather than delete the site, reverting the sharing scope to owner/admin only works instead.

Environment variables and secrets. Values that shouldn't appear in code or prompts, like API keys, go under Environment variables in site settings. That's the section shown with "+ Add variable" and "Nothing yet" on the settings screen described earlier.

Can you migrate an existing website in?

The short answer: there is no "import existing site" button. There's no migration feature that ingests a whole site from a URL, and no option in the documentation for connecting a GitHub repository.

Instead, there are two paths. One is deploying an existing project already managed through Codex, via Sites. A Sites project stores the link between local source code and hosting in .openai/hosting.json, and deployment is split into two steps: saving a version, then deploying. The official documentation notes that for an existing project, you should first ask ChatGPT to confirm the project can produce a compatible deployment artifact before requesting deployment. That single line reveals a lot about the nature of this feature — it isn't hosting that accepts anything, but hosting that only accepts specific formats.

The other path — likely the more common one in practice — is handing over materials and having the site rebuilt. Paste in the copy, images, and structure of the existing page, or provide screenshots, and ask for the same thing to be recreated. Since the domain can be pointed at the new site, visitors see no change in address.

The documentation is vague about what's unsupported. It's summed up in a single line: some frameworks, private networks, databases, background services, and hosting methods may not be supported. In practical terms, it breaks down like this.

This kind of site	Can it be migrated?
Static landing pages, portfolios	Faster to hand over materials and rebuild
Internal tools with accumulating data — forms, lists, dashboards	Good fit. D1/R2 cover this well
Sites relying on PHP, dedicated databases, or plugins, like WordPress	Not directly. Features must be selected and rebuilt individually
Pages tied to systems only accessible on an internal network	Private networks unsupported
Sites relying on scheduled batch or background jobs	Unsupported

What to check before publishing

The documentation includes a separate pre-launch checklist: confirm the site contains no confidential data, that access settings match the intended scope, that it doesn't violate workspace policy, and — if the site collects personal information — that doing so is appropriate.

Lines that must not be crossed are also spelled out. The service cannot process medical information or payment card data, and sites cannot target users under 13. Any e-commerce functionality must use an external payment processor. Above all, data residency and inference residency are not supported — this applies to deployed sites, site code, D1/R2 data and file storage, generated outputs, and logs.

Editor's take

One extra tab matters here because it shows where OpenAI is taking Sites. Building and deploying are already fully conversational. The gap left over was what happens after deployment. Once a site starts getting real use, data accumulates — and until now, seeing that data meant leaving ChatGPT entirely. This tab closes that loop. And the sequencing hints at what comes next: row editing, probably, followed by exports or SQL queries.

The fact that it shipped unannounced deserves separate attention. OpenAI documented the Analytics tab on the same screen down to its exact navigation path, and even announced its public test through its developer account. The Database tab got none of that. When the interface moves ahead of the documentation, users pay the cost — internal training materials and workflow guides fall out of sync with the actual screen, and anyone unaware the feature exists just keeps working the old way. If you're already using Sites, the faster move is to open the site detail screen yourself rather than wait for documentation to catch up.

Anyone who's used Lovable or similar tools will recognize where the real difference shows up. Plenty of tools can already build you a website, and generating that first screen happens at roughly the same speed everywhere. What separates them starts in week two. When 30 sign-ups have come in, is there a place to see that list? When 200 photos have piled up, can you tell what's eating storage? That's what determines whether a tool has staying power. ChatGPT Sites has just built that place — and for now, it's read-only.

Korean teams should separate what's worth trying now from what's premature. Things like an internal replacement for a Google Form, an event sign-up page, or a team tracker — where data runs to a few hundred rows and losing it wouldn't be catastrophic — are reasonable candidates to move over now. Anything handling customer personal data is still too early. Any organization required to answer where its data is physically stored will run straight into that one line about unsupported residency.

Shipping read-only first is itself a signal. Adding editing means also solving permissions, history, and how to undo an accidentally deleted row. A pure viewing screen needs none of that and can be shipped in days. It also suggests a judgment call: that the most common real-world need isn't "fix a value" but "see how many rows have come in so far." Anyone who's actually run an internal sign-up page knows the gap between how often you check it and how often you actually edit a value.

The real cost — in money and time — lies elsewhere. Sites are easy to build, so they keep multiplying. Every new site drags along a D1 table, and nobody cleans those up. Now that the Database tab exists, this is a good moment to sweep through your site list and delete anything unused. Since deletion requires typing the slug by hand, it's worth writing down what to keep and what to cut before starting.

Row editing will likely land within weeks. Products rarely ship a viewer and leave editing out indefinitely, and the screen's structure already assumes editing is coming. A grid with columns running off the edge and pagination controls at the bottom is built for a purpose — and that purpose is editing values.