diff --git a/_quarto.yml b/_quarto.yml
index cfb4a24b..1877532e 100644
--- a/_quarto.yml
+++ b/_quarto.yml
@@ -271,6 +271,10 @@ website:
             - docs/reactive-foundations.qmd
             - docs/reactive-patterns.qmd
             - docs/reactive-mutable.qmd
+        - section: "<span class='emoji-icon'>🗃️</span>  __Data__"
+          contents:
+            - docs/reading-data.qmd
+            - docs/persistent-storage.qmd
         - section: "<span class='emoji-icon'>📝</span>  __Syntax modes__"
           contents:
             - docs/express-vs-core.qmd
diff --git a/docs/apps/persistent-storage/app.py b/docs/apps/persistent-storage/app.py
new file mode 100644
index 00000000..79232024
--- /dev/null
+++ b/docs/apps/persistent-storage/app.py
@@ -0,0 +1,37 @@
+import polars as pl
+from setup import append_info, load_data, save_info
+from shiny import reactive
+from shiny.express import app_opts, input, render, ui
+
+with ui.sidebar():
+    ui.input_text("name_input", "Enter your name", placeholder="Your name here")
+    ui.input_checkbox("checkbox", "I like checkboxes")
+    ui.input_slider("slider", "My favorite number is:", min=0, max=100, value=50)
+    ui.input_action_button("submit_button", "Submit")
+
+# Load the initial data into a reactive value when the app starts
+data = reactive.value(load_data())
+
+
+# Append new user data on submit
+@reactive.effect
+@reactive.event(input.submit_button)
+def submit_data():
+    info = {
+        "name": input.name_input(),
+        "checkbox": input.checkbox(),
+        "favorite_number": input.slider(),
+    }
+    # Update the (in-memory) data
+    d = data()
+    data.set(append_info(d, info))
+    # Save info to persistent storage (out-of-memory)
+    save_info(info)
+    # Provide some user feedback
+    ui.notification_show("Submitted, thanks!")
+
+
+# Data grid that shows the current data
+@render.data_frame
+def show_results():
+    return render.DataGrid(data())
diff --git a/docs/apps/persistent-storage/gs-setup.py b/docs/apps/persistent-storage/gs-setup.py
new file mode 100644
index 00000000..7ce642a4
--- /dev/null
+++ b/docs/apps/persistent-storage/gs-setup.py
@@ -0,0 +1,32 @@
+import gspread
+import polars as pl
+
+# Authenticate with Google Sheets using a service account
+gc = gspread.service_account(filename="service_account.json")
+
+# Put your URL here
+sheet = gc.open_by_url("https://docs.google.com/spreadsheets/d/your_workbook_id")
+WORKSHEET = sheet.get_worksheet(0)
+
+import polars as pl
+
+# A polars schema that the data should conform to
+SCHEMA = {"name": pl.Utf8, "checkbox": pl.String, "favorite_number": pl.Int32}
+
+
+def load_data():
+    return pl.from_dicts(
+        WORKSHEET.get_all_records(expected_headers=SCHEMA.keys()), schema=SCHEMA
+    )
+
+
+def save_info(info: dict):
+    # Google Sheets expects a list of values for the new row
+    new_row = list(info.values())
+    WORKSHEET.append_row(new_row, insert_data_option="INSERT_ROWS")
+
+
+def append_info(d: pl.DataFrame, info: dict):
+    # Cast the boolean to a string for storage
+    info["checkbox"] = str(info["checkbox"])
+    return pl.concat([d, pl.DataFrame(info, schema=SCHEMA)], how="vertical")
diff --git a/docs/apps/persistent-storage/ibis-setup.py b/docs/apps/persistent-storage/ibis-setup.py
new file mode 100644
index 00000000..297166b0
--- /dev/null
+++ b/docs/apps/persistent-storage/ibis-setup.py
@@ -0,0 +1,24 @@
+import ibis
+import polars as pl
+
+# NOTE:  app.py should import CONN and close it via
+# `_ = session.on_close(CONN.disconnect)` or similar
+CONN = ibis.postgres.connect(
+    user="postgres", password="", host="localhost", port=5432, database="template1"
+)
+TABLE_NAME = "testapp"
+
+SCHEMA = {"name": pl.Utf8, "checkbox": pl.Boolean, "favorite_number": pl.Int32}
+
+
+def load_data():
+    return CONN.table(TABLE_NAME).to_polars()
+
+
+def save_info(info: dict):
+    new_row = pl.DataFrame(info, schema=SCHEMA)
+    CONN.insert(TABLE_NAME, new_row, overwrite=False)
+
+
+def append_info(d: pl.DataFrame, info: dict):
+    return pl.concat([d, pl.DataFrame(info, schema=SCHEMA)], how="vertical")
diff --git a/docs/apps/persistent-storage/pg-setup.py b/docs/apps/persistent-storage/pg-setup.py
new file mode 100644
index 00000000..4a38fc37
--- /dev/null
+++ b/docs/apps/persistent-storage/pg-setup.py
@@ -0,0 +1,19 @@
+import polars as pl
+
+URI = "postgresql://postgres@localhost:5432/template1"
+TABLE_NAME = "testapp"
+
+SCHEMA = {"name": pl.Utf8, "checkbox": pl.Boolean, "favorite_number": pl.Int32}
+
+
+def load_data():
+    return pl.read_database_uri(f"SELECT * FROM {TABLE_NAME}", URI)
+
+
+def save_info(info: dict):
+    new_row = pl.DataFrame(info, schema=SCHEMA)
+    new_row.write_database(TABLE_NAME, URI, if_table_exists="append")
+
+
+def append_info(d: pl.DataFrame, info: dict):
+    return pl.concat([d, pl.DataFrame(info, schema=SCHEMA)], how="vertical")
diff --git a/docs/apps/persistent-storage/s3-setup.py b/docs/apps/persistent-storage/s3-setup.py
new file mode 100644
index 00000000..e098467d
--- /dev/null
+++ b/docs/apps/persistent-storage/s3-setup.py
@@ -0,0 +1,36 @@
+from datetime import datetime
+
+import polars as pl
+
+DATA_BUCKET = "s3://my-bucket/data/"
+STORAGE_OPTIONS = {
+    "aws_access_key_id": "<secret>",
+    "aws_secret_access_key": "<secret>",
+    "aws_region": "us-east-1",
+}
+
+SCHEMA = {
+    "name": pl.Utf8,
+    "checkbox": pl.String,
+    "favorite_number": pl.Int32,
+    "date": pl.Datetime,
+}
+
+
+def load_data():
+    return pl.read_parquet(
+        f"{DATA_BUCKET}**/*.parquet", storage_options=STORAGE_OPTIONS
+    )
+
+
+def save_info(info: dict):
+    info["date"] = datetime.now()
+    new_row = pl.DataFrame(info, schema=SCHEMA)
+    new_row.write_parquet(
+        f"{DATA_BUCKET}", partition_by="date", storage_options=STORAGE_OPTIONS
+    )
+
+
+def append_info(d: pl.DataFrame, info: dict):
+    info["date"] = datetime.now()
+    return pl.concat([d, pl.DataFrame(info, schema=SCHEMA)], how="vertical")
diff --git a/docs/apps/persistent-storage/simple_form_app.jpeg b/docs/apps/persistent-storage/simple_form_app.jpeg
new file mode 100644
index 00000000..c504fd46
Binary files /dev/null and b/docs/apps/persistent-storage/simple_form_app.jpeg differ
diff --git a/docs/apps/reading-data/ibis-app.py b/docs/apps/reading-data/ibis-app.py
new file mode 100644
index 00000000..2aa78fe8
--- /dev/null
+++ b/docs/apps/reading-data/ibis-app.py
@@ -0,0 +1,36 @@
+import ibis
+from ibis import _
+from shiny.express import ui, render, input, session
+from shiny import reactive
+
+# Connect to the database (quick, doesn't load data)
+con = ibis.postgres.connect(
+    user="", password="", host="", port=, database=""
+)
+dat = con.table("weather")
+end_session = session.on_ended(con.disconnect)
+
+with ui.sidebar():
+    ui.input_checkbox_group(
+        "season",
+        "Season",
+        choices=["Summer", "Winter", "Autumn", "Spring"],
+        selected="Summer",
+    )
+    # Import just the unique city names for our selectize input
+    cities = dat.select("city_name").distinct().execute()["city_name"].to_list()
+    ui.input_selectize("city", "City", choices=cities)
+
+
+# Store data manipulations in a reactive calculation
+# (convenient when using the data in multiple places)
+@reactive.calc
+def filtered_dat():
+    return dat.filter(
+        [_.city_name == input.city(), _.season.isin(input.season())]
+    )
+
+# Display the filtered data
+@render.data_frame
+def results_df():
+    return filtered_dat().execute()
diff --git a/docs/apps/reading-data/polars-app.py b/docs/apps/reading-data/polars-app.py
new file mode 100644
index 00000000..dc99b1a8
--- /dev/null
+++ b/docs/apps/reading-data/polars-app.py
@@ -0,0 +1,32 @@
+import polars as pl
+from shiny import reactive
+from shiny.express import input, render, ui
+
+# Use `scan_*` instead of `read_*` to use the lazy API
+dat = pl.scan_parquet("./daily_weather.parquet")
+
+with ui.sidebar():
+    ui.input_checkbox_group(
+        "season",
+        "Season",
+        choices=["Summer", "Winter", "Fall", "Spring"],
+        selected="Summer",
+    )
+    # Import just the unique city names for our selectize input
+    cities = dat.select("city_name").unique().collect().to_series().to_list()
+    ui.input_selectize("city", "City", choices=cities)
+
+
+# Store manipulation in a reactive calc
+# (convenient for writing once and using in multiple places)
+@reactive.calc
+def filtered_dat():
+    return dat.filter(pl.col("city_name") == input.city()).filter(
+        pl.col("season").is_in(input.season())
+    )
+
+
+# Display the filtered data
+@render.data_frame
+def results_df():
+    return filtered_dat().collect()
diff --git a/docs/apps/reading-data/reactive-read-ibis-app.py b/docs/apps/reading-data/reactive-read-ibis-app.py
new file mode 100644
index 00000000..72445f5c
--- /dev/null
+++ b/docs/apps/reading-data/reactive-read-ibis-app.py
@@ -0,0 +1,18 @@
+import ibis
+from shiny.express import render
+from shiny import reactive
+
+con = ibis.postgres.connect(user="", password="", host="", port=, database="")
+table = con.table("tablename")
+
+def check_last_updated():
+    return table.last_updated.max().execute()
+
+# Every 5 seconds, check if the max timestamp has changed
+@reactive.poll(check_last_updated, interval_secs=5)
+def data():
+    return table.execute()
+
+@render.data_frame
+def result():
+    return data()
diff --git a/docs/persistent-storage.qmd b/docs/persistent-storage.qmd
new file mode 100644
index 00000000..38ac4c74
--- /dev/null
+++ b/docs/persistent-storage.qmd
@@ -0,0 +1,213 @@
+---
+title: Persistent data
+editor:
+  markdown:
+    wrap: sentence
+lightbox:
+  effect: fade
+---
+
+Shiny apps often need to save data, either to load it back into a different session or to simply log some information. In this case, it's tempting to save to a local file, but this approach has drawbacks, especially if the data must persist across sessions, be shared among multiple users, or be mutable in some way. Unfortunately, it may not be obvious this is a problem until you deploy your app to a server, where multiple users may be using the app at the same time.[^1]
+
+[^1]: Depending on the load balancing strategy of your [hosting provider](../get-started/deploy.qmd), you may be directed to different servers on different visits, meaning that data saved to a local file on one server may not be accessible on another server.
+
+In this case, instead of using the local file system to persist data, it's often better to use a remote data store. This could be a database, a cloud storage service, or even a collaborative tool like Google Sheets. In this article, we'll explore some common options for persistent storage in Shiny apps, along with some best practices for managing data in a multi-user environment.
+
+## An example: user forms {#user-form-example}
+
+To help us illustrate how to persist data in a Shiny app (using various backends), let's build on a simple user form example. In this app, users can submit their name, whether they like checkboxes, and their favorite number. The app will then display all the information that has been submitted so far.
+
+::: callout-warning
+### Pause here
+
+Before proceeding, make sure you read and understand the `app.py` logic below. This portion will stay fixed -- we'll only be changing only the `setup.py` file to implement different persistent storage backends.
+:::
+
+
+```{.python filename="app.py"}
+{{< include apps/persistent-storage/app.py >}}
+```
+
+![Simple Form Submission App](./apps/persistent-storage/simple_form_app.jpeg)
+
+Note that we're importing three helper functions from a `setup.py` file: `load_data()`, `save_info()`, and `append_info()`. These functions will be responsible for loading/saving data to persistent storage, as well as updating our in-memory data. For now, we'll just have some placeholders, but we'll fill these in with actual implementations in the next section.
+
+```{.python filename="setup.py"}
+import polars as pl
+
+# A polars schema that the data should conform to
+SCHEMA = {"name": pl.Utf8, "checkbox": pl.String, "favorite_number": pl.Int32}
+
+# A template for loading data from our persistent storage
+def load_data():
+    return pl.DataFrame(schema=SCHEMA)
+
+# A template for saving new info to our persistent storage
+def save_info(info: dict):
+    pass
+
+# Helper to append new info to our in-memory data
+def append_info(d: pl.DataFrame, info: dict):
+    return pl.concat([d, pl.DataFrame(info, schema=SCHEMA)], how="vertical")
+```
+
+## Persistent storage options
+
+As long as you can read/write data between Python and a data store, you can use it as persistent storage with Shiny. Here are some common options, along with some example implementations.
+
+### Google Sheets
+
+Google Sheets is a great lightweight option for persistent storage. It has a familiar web interface, built-in sharing and collaboration features, and a free tier that is sufficient for many applications.
+There's also a nice library, [`gspread`](https://docs.gspread.org/en/latest/index.html), that makes it easy to read and write data to Google Sheets.
+We'll use it here to demonstrate how to persist data in a Shiny app.
+
+
+::: callout-note
+### Authentication
+
+In order to use Google Sheets as a data store, you'll need to set up authentication with Google. Try following the authentication instructions in the [`gspread` documentation](https://docs.gspread.org/en/latest/oauth2.html). Your organization may or may not support creating your own service account, so you may have to contact your IT department if you can't create one on your own.
+:::
+
+
+```{.python filename="setup.py"}
+{{< include apps/persistent-storage/gs-setup.py >}}
+```
+
+
+Although Google Sheets is a nice, simple option for data collection, there are a number of reasons why you may prefer a more sophisticated option (e.g., security, governance, efficiency, concurrency, etc.).
+In the next example, we'll replace our Google Sheets workbook with a (Postgres) database. This gets us much closer to a traditional web application, with a persistent database for storage and all the standard database features like transaction locking, query optimization, and concurrency management.
+
+### Cloud storage
+
+Polars provides built-in support for working with [cloud storage services](https://docs.pola.rs/user-guide/io/cloud-storage/) like AWS S3, Google Cloud Storage, and Azure Blob Storage.
+
+Efficiently updating data in cloud storage can be tricky, since these services are typically optimized for large, immutable files. That said, if your data can be stored in a columnar format like Parquet, you can take advantage of partitioning to efficiently append new data without having to rewrite the entire dataset.
+
+```{.python filename="setup.py"}
+{{< include apps/persistent-storage/s3-setup.py >}}
+```
+
+::: callout-tip
+### Pins
+
+[Pins](https://rstudio.github.io/pins-python/) offers another option for working with cloud storage. It provides a higher-level interface for storing and retrieving data, along with built-in support for versioning and metadata. Pins offers some nice cloud storage integrations you may not find elsewhere, like [Posit Connect](https://pins.rstudio.com/reference/board_connect.html) and [Databricks](https://pins.rstudio.com/reference/board_databricks.html).
+:::
+
+### Databases {#databases}
+
+Compared to cloud storage, databases offer a much more robust option for persistent storage. They can handle large datasets, more complex queries, and offer concurrency guarantees. There are many different types of databases, but for this example, we'll use Postgres, a popular open-source relational database. That said, Polars (and other libraries) [support many different databases](https://docs.pola.rs/user-guide/io/database/), so you can adapt this example to your preferred database system.
+
+::: callout-tip
+### Authentication
+
+When connecting to a database, it's important to keep your credentials secure. Don't hard-code your username and password in your application code. Instead, consider using environment variables or a secrets manager to store your credentials securely.
+:::
+
+```{.python filename="setup.py"}
+{{< include apps/persistent-storage/pg-setup.py >}}
+
+```
+
+::: {.callout-note collapse="true"}
+### What about Ibis?
+
+Ibis is another useful Python package for working with databases. It may be a preferable option to Polars if you need more complex queries and/or read from multiple tables efficiently.
+
+```{.python filename="setup.py"}
+{{< include apps/persistent-storage/ibis-setup.py >}}
+```
+:::
+
+
+## Adding polish
+
+The [user form example](#user-form-example) that we've been building from is a good start, but there are a few things we could do to make it a bit more robust, user-friendly, and production-ready.
+First, let's assume we're using a [database backend](#databases), since that is the robust and scalable option for production apps.
+
+### Error handling
+
+The app currently doesn't handle any errors that may occur when loading or saving data. For example, if the database is down or the Google Sheets API is unreachable, the app will crash. To make the app more robust, consider adding error handling to `load_data()` and `save_info()` in `setup.py`. For example, you could use try/except blocks to catch exceptions and re-throw them as `NotifyException`, which will display a notification to the user without crashing the app. This could like something like changing this line in `app.py`:
+
+```python
+data = reactive.value(load_data())
+```
+
+to
+
+```python
+from shiny.types import NotifyException
+
+data = reactive.value()
+
+@reactive.effect
+def _():
+    try:
+        data.set(load_data())
+    except Exception as e:
+        raise NotifyException(f"Error loading data: {e}") from e
+```
+
+### Sharing data
+
+Suppose two users visit our app at the same time: user A and user B. Then, user A submits their info, which gets saved to the database. This action won't affect user B's in-memory view of the data, since `load_data()` only gets called once (when a user first visits the app). If we wanted _all_ users to see the updated data whenever _any_ user submits data, we could move the line:
+
+```python
+data = reactive.value(load_data())
+```
+
+from the `app.py` file to the `setup.py` file -- this changes `data` from being a user-scoped reactive value to a globally-scoped reactive value (i.e. [shared among all users](express-in-depth.qmd#shared-objects)).
+
+Sharing data in this way works fine when only users can change the data, but it wouldn't work in a scenario where data can be changed outside of the app (e.g., another app or a database admin). In this case, we would need to periodically check for updates using something like [reactive polling](reading-data.qmd#reactive-reading).
+
+### SQL injection
+
+When working with databases, it's important to be aware of SQL injection attacks. These occur when an attacker is able to manipulate your SQL queries by injecting malicious code via user inputs. In our example, we don't have any user inputs that are directly used in SQL queries, so we're safe. However, if you do have user inputs that are used in SQL queries, make sure to use parameterized queries or an ORM to avoid SQL injection attacks. For example, if we wanted to allow users to filter the data by name, we could add a text input to the UI and then modify the `load_data()` function to use a parameterized query.
+
+### Limit user access
+
+Apps that need to persist data often need to restrict access to the app (and/or underlying data). For example, your app might need users to authenticate in order to be accessed, or you might want to allow some users to view data but not submit new data. If your app requires user authentication and/or fine-grained access control, consider using a hosting provider that supports these features out-of-the-box, like Posit [Connect](https://solutions.posit.co/secure-access) or [Connect Cloud](https://docs.posit.co/connect-cloud/user/share). These platforms provide built-in authentication and access control features that make it easy to manage user access.
+
+::: callout-note
+### Want to roll your own?
+
+Since Shiny is built on FastAPI and Starlette, you can also implement your own authentication and access control mechanisms using standard Python libraries like [FastAPI Users](https://fastapi-users.github.io/fastapi-users/) or [Authlib](https://docs.authlib.org/en/latest/). However, this approach requires significant work and maintenance on your part, so it's generally recommended to use a hosting provider that supports these features if possible.
+:::
+
+## Deployment
+
+### Prod vs dev
+
+Before deploying your app into production, consider that you likely don't want to use your production data store for testing and development. Instead, consider setting up at least two different data stores: one for production and one for development. Generally speaking, environment variables work great for switching between different backends. For example, you could set an environment variable `APP_ENV` to either `prod` or `dev`, and then use that variable to determine which backend to use in `setup.py`.
+
+```{.python filename="setup.py"}
+import os
+import polars as pl
+from dotenv import load_dotenv
+
+load_dotenv()
+
+# In your production environment, set APP_ENV=prod
+ENV = os.getenv("APP_ENV")
+
+if ENV == "prod":
+    URI = "postgresql://postgres@localhost:5432/prod_db"
+    TABLE_NAME = "prod_table"
+else:
+    URI = "postgresql://postgres@localhost:5432/dev_db"
+    TABLE_NAME = "dev_table"
+```
+
+In fact, you may also want to consider using different credentials for different environments: one for you (the developer) and one for the production app. This way, you'll minimize the risk of accidentally writing test data to your production database.
+
+### Cloud
+
+The quickest and easiest way to deploy your app is through [Posit Connect Cloud](https://connect.posit.cloud/), which has a generous [free tier](https://connect.posit.cloud/plans). All you need is your app code and a `requirements.txt` file. From there, you can deploy via a Github repo or from within [VSCode](https://code.visualstudio.com/)/[Positron](https://positron.posit.co/) via the [Publisher extension](https://marketplace.visualstudio.com/items?itemName=Posit.publisher). Note that its [encrypted secrets](https://connect.posit.cloud/plans) feature will come in handy for authenticating with your persistent storage backend.
+
+To learn more about other cloud-based deployment options, see [here](../get-started/deploy-cloud.qmd).
+
+### Self-hosted
+
+If you or your organization prefers to self-host, consider [Posit Connect](https://posit.co/products/connect), which is Posit's flagship publishing platform for the work your teams create in Python or R.
+Posit Connect is widely used in highly regulated environments, with strict security and compliance requirements. It includes robust features for managing user access, scheduling content updates, and monitoring application performance. Note that its [content settings panel](https://docs.posit.co/connect/user/content-settings/) will come in handy for configuring environment variables and other settings needed to connect to your persistent storage backend.
+
+To learn more about other self-hosted deployment options (including free and open source ones), see [here](../get-started/deploy-on-prem.qmd).
diff --git a/docs/reading-data.qmd b/docs/reading-data.qmd
new file mode 100644
index 00000000..1ebca35d
--- /dev/null
+++ b/docs/reading-data.qmd
@@ -0,0 +1,333 @@
+---
+title: Reading data
+editor:
+  markdown:
+    wrap: sentence
+lightbox:
+  effect: fade
+---
+
+From local files, databases, cloud-hosted data stores, and beyond, if you can read your data into Python, you can also read it into Shiny. Here we'll highlight some of our recommended ways to read data, which can be grouped into two main categories: [eager](#eager) and [lazy](#lazy) loading.
+
+By eager, we mean loading all your data into memory when the app first starts. By lazy, we mean loading _portions_ of data into memory _as needed_. The eager approach is generally recommended for small to moderately sized datasets -- for larger data, lazy loading may be necessary, but it will add complexity to your app logic.
+
+## Eager loading {#eager}
+
+Loading all your data into memory when your app first starts is the simplest way to work with data in Shiny.
+This makes it easy to create UI from data, and more generally reason about your app's data logic. However, this also means that before a user can interact with your app, the data must finish being loaded into memory, so be mindful to keep this step as fast and efficient as possible (or consider [lazy](#lazy) loading).
+
+### From a file
+
+If your data lives in a file (e.g., CSV, Parquet, etc.), you can read it into memory using a variety of tools. Popular libraries for this include [Polars](https://pola.rs/), [DuckDB](https://duckdb.org/), and [Pandas](https://pandas.pydata.org/):
+
+::: {.panel-tabset .panel-pills}
+
+#### Polars
+
+[Polars](https://pola.rs/) is a fantastic library that makes data manipulation fast and intuitive. We recommend starting here for most data analysis tasks in Shiny apps.
+
+```python
+import polars as pl
+dat = pl.read_csv(Path(__file__).parent / "my_data.csv")
+```
+
+#### DuckDB
+
+[DuckDB](https://duckdb.org/) is a fast analytical database system. It's a great choice to quickly import data into memory.
+
+```python
+import duckdb
+from pathlib import Path
+
+dat = duckdb.read_csv(Path(__file__).parent / "my_data.csv")
+```
+
+#### Pandas
+
+[Pandas](https://pandas.pydata.org/) is a widely used data manipulation library in Python. While it may not be as fast and ergonomic as Polars for large datasets, it is still a solid choice for many apps.
+
+```python
+import pandas as pd
+from pathlib import Path
+
+dat = pd.read_csv(Path(__file__).parent / "my_data.csv")
+```
+:::
+
+### From a database
+
+If your data lives in a database, reading it into memory can be done using similar tools like Polars. Most databases have a connection interface via [SQLAlchemy](https://www.sqlalchemy.org/), which has integration with packages like Polars (and Pandas):
+
+```python
+import polars as pl
+dat = pl.read_database_uri(
+    "SELECT * FROM tablename",
+    "postgresql://user:password@hostname/database_name"
+)
+```
+
+
+See [Polars](https://docs.pola.rs/user-guide/io/database/) and [SQLAlchemy's](https://docs.sqlalchemy.org/en/20/core/engines.html) docs for more info, like connecting to other database types.
+
+
+::: callout-tip
+### Multiple tables
+
+`pl.read_database_uri()` opens a connection to the database, runs the provided query, and then closes the connection. If you need to read multiple tables, consider using a database-centric library like [Ibis](https://ibis-project.org/) to manage the connection and queries more effectively.
+We'll cover this (explicitly opening/closing connections) more in the [lazy loading](#lazy) section below.
+:::
+
+
+### From the cloud
+
+Polars can read Parquet, CSV, IPC, and NDJSON files directly from cloud storage providers such as AWS, Azure, and Google Cloud Storage.
+
+Depending on the provider, you will have to set up the appropriate [credentialing](https://docs.pola.rs/user-guide/io/cloud-storage/#cloud-authentication). Once you've done so, reading from the cloud is just like reading from a file on disk.
+
+```python
+import polars as pl
+dat = pl.read_parquet("s3://bucket/yourfile.parquet")
+```
+
+For more, see Polars' [cloud storage documentation](https://docs.pola.rs/user-guide/io/cloud-storage/).
+
+### Performance tips
+
+When eagerly reading data into memory, it's important to consider the performance implications. Here are some tips to help keep your app fast and responsive:
+
+#### Express
+
+When in Express mode (i.e., using `shiny.express`), we highly recommended reading data (or other expensive setup code) in a separate module, then importing it into your `app.py` file. This ensures the data is loaded only once, improving performance. For more details, refer to the Express documentation [here](express-in-depth.qmd#shared-objects).
+
+```{.python filename="setup.py"}
+import polars as pl
+from pathlib import Path
+
+dat = pl.read_csv(Path(__file__).parent / "my_data.csv")
+```
+
+```{.python filename="app.py"}
+from shiny.express import render
+from setup import dat
+
+@render.data_frame
+def df():
+    return dat
+```
+
+#### Large data
+
+If you have larger data, eagerly reading all of it into memory may not be feasible, so you may need a smarter approach than loading it all into memory when your app first starts. The next section covers some more advanced techniques for lazily loading data into memory as needed.
+
+However, before reaching for lazy loading (which will add complexity to your app), consider the following optimizations for reading data into memory:
+
+1. **File format**: Use efficient file formats like Parquet instead of CSV for large datasets.
+2. **ETL process**: Preprocess and clean your data before loading it into your app to reduce size and complexity.
+3. **Database optimization**: If reading from a database, ensure it's optimized for analytical queries (e.g., using indexes, partitioning, etc.).
+
+## Lazy reading {#lazy}
+
+Some datasets are too costly to read into memory when an app first loads. In this situation, we can leverage tools to lazily load data into memory as needed, helping keep our app fast and responsive.
+
+### From a file
+
+A fantastic tool for lazily reading data from a file is [Polars' Lazy API](https://docs.pola.rs/user-guide/lazy/). This way, you can write data manipulations and only perform them when you need to `.collect()` results. This looks something roughly like this:
+
+```python
+import polars as pl
+from shiny.express import render
+from pathlib import Path
+
+# Executes instantly (it doesn't load the data into memory)
+dat = pl.scan_parquet(Path(__file__).parent / "test_data.parquet")
+
+@render.data_frame
+def df():
+    # Express manipulations and .collect() only when needed
+    return dat.head(100).collect()
+```
+
+::: callout-tip
+### Cloud-based files
+
+Polars also supports lazy reading from [cloud storage](https://docs.pola.rs/user-guide/io/cloud-storage/). This is very helpful for limiting how much information is downloaded to memory, especially if you only need a small portion of a much larger dataset for your application (e.g., You have data from 1900-present but you only need 2000-present.)
+
+```python
+import polars as pl
+
+source = "s3://bucket/yourfile.parquet"
+dat = pl.scan_parquet(source).filter("your filter here").collect()
+```
+:::
+
+If you have a choice, we recommend using Polars' Lazy API over running queries against a database, as it is often simpler and faster. That said, there are certainly cases where a database is more appropriate or necessary.
+
+
+### From a database
+
+Some fantastic tools for lazy loading data from a database are [Ibis](https://ibis-project.org/) and [SQLAlchemy](https://www.sqlalchemy.org/). With these tools, you can connect to practically any database and express data manipulations in Python (or SQL with SQLAlchemy). Your data manipulations are only executed when you call `.execute()`, similar to Polars' `.collect()`.
+
+When using these tools, it's important to explicitly open and close the database connection to avoid connection leaks.
+
+Here's an example using Ibis with a PostgreSQL database:
+
+```bash
+pip install 'ibis-framework[postgres]'
+```
+
+```python
+import ibis
+from shiny.express import render, session
+
+# Connect to the database (nearly instant)
+con = ibis.postgres.connect(
+    user="username",
+    password="password",
+    host="hostname",
+    port=5432,
+    database="database",
+)
+dat = con.table("tablename")
+
+# Cleanup connection when the session ends
+_ = session.on_ended(con.disconnect)
+
+@render.data_frame
+def df():
+    # Perform manipulations and .execute() only when needed
+    return dat.head(100).execute()
+```
+
+::: callout-tip
+### Using SQL directly
+
+If you prefer to write SQL more directly, use SQLAlchemy to connect to your database and execute SQL queries. This approach provides more flexibility but requires more manual handling of SQL queries.
+
+<details>
+<summary>Show example code</summary>
+
+```python
+from shiny.express import render
+from sqlalchemy import create_engine, text
+
+engine = create_engine('postgresql://user:password@hostname/database_name')
+with engine.connect() as conn:
+    dat = conn.execute(text("SELECT * FROM tablename LIMIT 100"))
+```
+</details>
+:::
+
+### A real example
+
+Let's look at an example with the [The Weather Dataset](https://www.kaggle.com/datasets/guillemservera/global-daily-climate-data). This data is fairly large (nearly 28M rows), but by loading it lazily, we can keep our app responsive.
+
+::: {.panel-tabset .panel-pills}
+
+#### Polars (file)
+
+```python
+{{< include apps/reading-data/polars-app.py >}}
+```
+
+#### Ibis (database)
+
+```python
+{{< include apps/reading-data/ibis-app.py >}}
+```
+:::
+
+
+## Examples
+
+We have numerous full examples and starter templates of dashboards using different datastores. We've sorted them into categories roughly corresponding to the tech stack.
+
+::: {.panel-tabset .panel-pills}
+
+#### Polars
+::: {layout-ncol=2}
+##### Restaurant Tips Dashboard Template
+![Restaurant tips dashboard](../templates/dashboard-tips/thumbnail.png)
+[See the code](https://shiny.posit.co/py/templates/dashboard-tips/)
+
+##### Model Scoring Dashboard Template
+![Model scoring dashboard](../templates/model-scoring/thumbnail.png)
+[See the code](https://shiny.posit.co/py/templates/model-scoring/)
+:::
+
+#### DuckDB
+
+::: {layout-ncol=2}
+##### Query Explorer Template
+
+![DuckDB Query Explorer App](../templates/database-explorer/thumbnail.png)
+[See the code](https://shiny.posit.co/py/templates/database-explorer/)
+
+##### Identify Outliers App
+
+![Identify Outliers App](../gallery/identify-outliers.jpg)
+[See the code](https://github.com/skaltman/outliers-app-db-python/)
+:::
+
+#### Pandas
+
+::: {layout-ncol=2}
+##### AWS Community Builders App
+
+![AWS Community Builders App](../gallery/aws-builders.jpg)
+[See the code](https://github.com/robertgv/aws-community-builders-dashboard)
+:::
+
+:::
+
+## Reactive reading {#reactive}
+
+In some cases, you may need your app to occasionally re-read an updated data source _while the app is running_. This is particularly important in scenarios where multiple users may be writing to the database [^1] and/or there may be automated processes updating your data. While, this is a more advanced use case, Shiny provides tools to help with this scenario.
+
+[^1]: We'll talk more about writing to data stores from Shiny in our article on [Persistent Storage](persistent-storage.qmd)
+
+### From a file
+
+If your data lives in a local file, use [`reactive.file_reader()`](https://shiny.posit.co/py/api/express/reactive.file_reader.html) to monitor the file for changes and re-read it when it changes.
+By default, `reactive.file_reader()` checks the file's modification time every second, but you can adjust this with the `interval` argument.
+
+```python
+import pathlib
+import polars as pl
+from shiny import reactive
+from shiny.express import render
+
+file = pathlib.Path(__file__).parent / "mtcars.csv"
+
+@reactive.file_reader(file)
+def read_file():
+    return pl.read_csv(file)
+
+@render.data_frame
+def result():
+    return read_file()
+```
+
+### From a database
+
+If your data lives in a database, use [`reactive.poll()`](https://shiny.posit.co/py/api/express/reactive.poll.html) to periodically check if the data has changed and re-read it when it has.
+With `reactive.poll()`, you're required to provide a function to check if the data has changed, which should be as efficient as possible.
+Unfortunately, there is no universal way to check if data has changed in a database, so you'll need to implement this logic based on your specific use case.
+In general, you might check a "last updated" timestamp column:
+
+```python
+{{< include apps/reading-data/reactive-read-ibis-app.py >}}
+```
+
+::: callout-note
+### Polling to export to file
+
+Since Polars is so good at (lazily) reading data from files, it's tempting to export from a database to a file. In this case, you could set up a `reactive.poll()` to save the database table as a file whenever it changes, and `reactive.file_reader()` to re-read the file when the file changes.
+:::
+
+
+For a deeper dive into reactively reading "streaming" data, see the [Streaming Data](../templates/monitor-database/index.qmd) template.
+
+
+## What about saving data?
+
+In some cases, you may need to save data from your application back to a database or other remote location. This is a more advanced use case, but Shiny provides tools to help with this scenario. In the next article, we'll cover some strategies for persisting data from your Shiny app.
diff --git a/templates/dashboard-tips/index.qmd b/templates/dashboard-tips/index.qmd
index d750d3aa..181beea5 100644
--- a/templates/dashboard-tips/index.qmd
+++ b/templates/dashboard-tips/index.qmd
@@ -53,7 +53,7 @@ Another notable difference is the use of `plotly` for interactive plots.
 **Packages:**
 
 * `faicons`
-* `pandas`
+* `polars`
 * `plotly`
 * `shinywidgets`
 :::
diff --git a/templates/model-scoring/index.qmd b/templates/model-scoring/index.qmd
index a1247f88..3ede7add 100644
--- a/templates/model-scoring/index.qmd
+++ b/templates/model-scoring/index.qmd
@@ -46,8 +46,8 @@ Shiny's reactive programming model makes it easy and performant to update those
 
 **Packages:**
 
-* `numpy`
-* `pandas`
+* `polars`
+* `pyarrow`
 * `plotnine`
 * `scikit-learn`