Summary
- A Database tab has appeared on the ChatGPT Sites site management screen. It shows the columns and rows of a site's D1 tables directly inside ChatGPT
- Connection status, table list, columns and rows, pagination, and Refresh are all supported. There is still no cell editing or row add/delete button — it's read-only for now
- For sites with application forms or photo uploads attached, there's no longer any need to leave ChatGPT to check whether values actually came in
The number 1,272,167 showed up on the management screen
Upload a photo to a website built with ChatGPT. The photo appears on the site as-is, and a row is left behind in the management screen: a file key, image/png, 1272167, 2026-08-17 06:55:19. 1,272,167 bytes is roughly 1.2 megabytes — about the size of a single photo taken on a smartphone. A new place has appeared inside ChatGPT to check that row with your own eyes.
A Database tab has been added to ChatGPT Sites, OpenAI's website-building feature. It sits in the third spot on the site detail screen, next to Settings and Analytics. This is the first place where you can check the data accumulated by a site in table form without leaving ChatGPT. The earliest confirmed screenshot of it in action is dated August 17, and neither the release notes nor the help center has published a description of this tab yet.
There was also movement on the documentation side around the same period. Comparing a copy from the Web Archive dated August 10 with the current Sites guide side by side shows that a table listing the storage limits attached to a site was newly added in between: D1 at 10GB, R2 with no fixed limit. It's the D1 side that this new tab lets you look into.
What is ChatGPT Sites
Sites is a feature that lets you build websites and lightweight apps inside ChatGPT and have them hosted right there. It first opened as a preview on June 2 for business and enterprise workspaces using Codex, then moved to public beta in the July 9 ChatGPT release notes. OpenAI describes it as a feature that turns work or ideas into interactive websites without ever leaving ChatGPT. The main targets are pages that aren't especially large in scope — dashboards, application forms, internal trackers, calculators.
A site you build gets an address in the form sitename.username.chatgpt.site. If you own a domain, you can edit your DNS records to connect it, but Sites itself does not purchase or register domains on your behalf. As of launch, enterprise workspaces could not use custom domains.
Data handling is the backdrop for this story. Official documentation describes two kinds of storage attached to a site. D1 is the relational database that holds data meant to persist in table form; R2 is the object storage that holds the original files. The names D1 and R2 match products of the same names sold by Cloudflare — a relational database and object storage, respectively. OpenAI's documentation uses only the names and doesn't specify which company's products they are.
| Storage | What it holds | Limit |
|---|---|---|
| D1 | Table-form data like applicant lists, status values, logs | 10GB per site |
| R2 | Original files like photos, PDFs, videos | No fixed limit |
The two storage types have distinct roles. When you upload a photo, the original file goes to R2, while D1 gets a single row recording where that file is (object_key), plus its format, size, and creation time. The 1272167 figure mentioned earlier is exactly that row.
What the Database tab actually shows
The screen title reads "Database," with the description below it: "View the data used by your live site." Connection status and a table list sit on the left, and the columns and rows of the selected table appear on the right.
| Screen element | What it tells you |
|---|---|
| "Connected" indicator | Whether the site is linked to a database |
| TABLES list | The names of all tables attached to this site |
| Table area | Column names and actual rows. If there are many columns, you scroll horizontally |
| "Showing 1–6" | Which row range the current screen is displaying |
| ← → buttons | Move to the next or previous set of rows |
| Refresh button | Reloads the data as it currently stands |
The confirmed screenshot 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, holding the metadata for a single photo. Even with a small number of rows, Showing 1–6 and the pagination buttons still appear beneath the table.
Read-only for now
The confirmed screenshots show no buttons for editing cells or adding/deleting rows. To change a value, you still have to ask ChatGPT to modify the site's code, or enter data through an input form already built into the site. At this stage, it functions less like a database management screen and more like a viewer for re-checking live data.
Still, something has changed. Until now, if you built a form or gallery with Sites, you could only guess what shape the data actually took by looking at what showed up on screen. Now you can look at the tables and columns directly before deciding what to ask for next.
How to build one
Where to start. On the web, choose Work. In the desktop app, choose ChatGPT and then go into Work, or choose Codex instead. Use the Create button in the top right of the list screen to make a new site; for sites you've already made, click the name in the Sites list in the sidebar, or choose Settings from the "…" menu on the right to go to the detail screen. The Database tab is at the top of that detail screen.
Step-by-step.
The first five steps follow the order given in the help center exactly. The remaining four steps cover checking the newly added tab as well.
- In the chat window, describe to ChatGPT the website you want to build. Including the word "website" in your prompt, or mentioning
@Sites, reliably routes it into a Sites task. - Provide the materials you'll use. The documentation lists five categories: content, files, data, links, and constraints. Give logo files, exact copy to include, reference page addresses, and conditions like "it must fit on a single mobile screen" all at once at this stage. Skipping this and fixing things one at a time later leads to more back-and-forth.
- If you need to accumulate data, list out what should be stored. Something like "an application page that saves the applicant's name, email, and submission time to a database" is enough for ChatGPT to build a matching table and attach it to the site.
- Review the preview ChatGPT generates. Up to this point, no one else can see it.
- Request edits until it's ready to share or publish. Fix copy, colors, fields, and behavior through instructions.
- Deploy. Once deployment finishes, you get an address in the form
name.username.chatgpt.site. - Set the access scope. There are four options: owner and admins only; specific chosen people or groups; the entire workspace; or the entire internet. The last option, in enterprise workspaces, must first be enabled by an administrator.
- Actually put data into the site. Fill out and submit a form, or upload a photo.
- Open the Database tab on the site detail screen. Choose a table on the left and check whether the value you just entered has come in as a row. If it doesn't appear, click Refresh in the top right.
Who can use it. It's not available on the Free or Go plans. Business and Enterprise got it first via the June 2 Codex preview; Pro, Pro Lite, and Edu were opened 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 it had opened access to Plus and Pro users in those regions as well. Korea was never among the excluded regions.
| Item | Condition |
|---|---|
| Plan | Any paid plan except Free and Go (public beta) |
| Region | EEA, Switzerland, UK excluded at launch → opened to Plus/Pro users there on July 20 |
| Entry point | ChatGPT web Work · desktop app Work or Codex |
| Enterprise workspace | Admins grant creation and publishing permissions separately |
| Visitor verification | Sites can require login with a ChatGPT account |
| Custom domain | Connect an owned domain via DNS; excluded for enterprise workspaces as of launch |
What you can try. Build an internal study-group signup page, and every time someone applies, a row is added to the D1 table, letting you instantly count applicants in the Database tab. Build a team photo archive, and while the originals go to R2, the file name, size, and upload time stay in D1 so you can check in table form which files are the heaviest. Attach ChatGPT login to a site, and visitor emails and names come through as the oai-authenticated-user-email and oai-authenticated-user-full-name headers, so you can even record who submitted what in the table.
How to edit, share, and take a site down
Editing tends to happen more often than building. Here's the process as laid out in the help center documentation.
Editing. Reopen the conversation you used to build 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, style, links, forms, and interactive behavior as examples. Review the updated preview and, if there's more to fix, describe it again.
Saving and deploying are separate steps. To check a set of changes without touching the live site, first save a version, and only deploy once you're satisfied with the review. Conflating these two steps means unreviewed screens go straight to live.
Changing the sharing scope. In the preview, click share and choose from "who has access." There are four options: 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.
- Open site settings and click "Add domain."
- Enter a root domain or subdomain.
- Copy the DNS records and values Sites provides and add them exactly as given to your domain provider (Gabia, Whois, Cloudflare, etc.).
- Wait a few minutes, then refresh the domain status in Sites.
Taking down and deleting. Open Sites in the sidebar and click delete site. In the dialog, you must manually type the site slug for permanent deletion to activate. If you just want to stop publishing, you can revert the sharing scope to owner/admin only instead of deleting.
Environment variables and secrets. Values that shouldn't be left in code or prompts, like API keys, go into Environment variables in site settings. This is the "+ Add variable" and "Nothing yet" area shown in the settings screen mentioned earlier.
Can you migrate an existing website?
The short answer is: there is no "import existing site" button. There's no migration feature that ingests everything by URL, and no option to connect a GitHub repository in the documentation.
Instead, there are two paths. One is deploying an existing project already managed by Codex through Sites. Sites projects store the connection info linking local source and hosting in .openai/hosting.json, and deployment is split into save-version and deploy steps. Official documentation states that for existing projects, you should first ask ChatGPT to confirm the project can produce compatible deployment output before requesting a deploy. This single line reveals the nature of the feature — it's hosting that only accepts certain shapes, not hosting that accepts anything.
The other path — likely the one used more often in practice — is handing over the materials and rebuilding. You paste in the copy, images, and structure of an existing page, or provide screenshots, and ask for the same thing to be recreated. Since domains can be transferred over, the address stays the same from a visitor's perspective.
The documentation lumps together what isn't supported. It's a single line stating that 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 intro/landing pages, portfolios | Faster to hand over materials and rebuild |
| Internal tools where data accumulates — forms, lists, dashboards | Fits well. D1/R2 fill that role |
| Sites relying on WordPress-style PHP, dedicated databases, plugins | Can't be moved as-is. Individual features need to be rebuilt |
| Pages tied to systems only accessible on an internal network | Private networks unsupported |
| Recurring batch or background jobs | Unsupported |
What to check before publishing
The documentation also has a separate pre-publish checklist. It says to check whether the site contains confidential data, whether the access settings match the intended scope, whether it conflicts with workspace policy, and — if it collects personal information — whether that collection is appropriate.
The lines that must not be crossed are also explicit. It cannot process medical information or payment card information, and sites targeting children under 13 aren't allowed either. If you're attaching e-commerce, payments must go through an external payment processor. Above all, it does not support data residency or inference residency — this applies to deployed sites, site code, D1/R2 data and file storage, output, and logs, all of it.
Vibe-coding startup Lovable doubles valuation in eight months
Editor's take
The reason a single added tab is worth taking seriously is that it shows where OpenAI is steering Sites. Building and deploying are already handled entirely through conversation. The remaining gap was what happens after deployment. Once a site starts running, data accumulates, but checking that data meant leaving ChatGPT. This tab closes that loop. Following the sequence, it's fairly easy to guess what comes next: row editing, then downloading or SQL queries.
The documentation still hasn't caught up with this tab. So any internal manual built purely from the official guide is now a step out of sync with the actual screen. If your team uses Sites, open a site's detail screen and check whether there are three tabs, then add a line to your manual: "check data in the Database tab."
Anyone who has used Lovable or similar tools will recognize where the real difference shows up. Plenty of tools already build websites, and the speed of producing a first screen is roughly comparable across them. What differs is what happens from the second week onward. A tool's staying power gets decided by whether there's a place to see the list once 30 applicants have signed up, or to check what's eating up storage once 200 photos have piled up. ChatGPT Sites has just now created that place, and it's still read-only.
What Korean teams should try now and what's still too early for should be kept separate. It makes sense to start by moving things like internal Google Forms replacements, event signup pages, or department trackers — cases where the data is a few hundred rows and nothing catastrophic happens if it's lost. On the other hand, services handling customer personal information are still too early. Any organization that has to answer which country its data is stored in will run into that single line about unsupported residency.
The choice to ship read-only first is itself a signal. Adding editing means also solving permissions, history, and the problem of recovering an accidentally deleted row. A display-only screen needs none of that, so it can be shipped in days. It also implies a judgment that the most common real-world need isn't "fix a value" but "see how many rows have come in so far." If you've run an internal signup page, you know the gap between how often you check it and how often you actually edit a value is large.
The place where time and money actually leak is elsewhere. Sites makes pages so easy to build that they keep multiplying. Every new site brings its own D1 table, and no one cleans those up. Now that the Database tab exists, this is a good moment to sweep through your site list and delete what's no longer in use. Since deletion requires manually typing the slug, it's worth writing down what to keep and what to delete on paper first, before you start.
Row editing will likely be added within a few weeks. Products rarely ship a viewer and then delay editing for long, and the screen structure already seems built with editing in mind. A grid with columns running off the right edge of the table and pagination at the bottom looks like it was made to have its values changed.
Comments