{"id":122077,"date":"2026-07-09T08:56:03","date_gmt":"2026-07-09T03:26:03","guid":{"rendered":"https:\/\/www.guvi.in\/blog\/?p=122077"},"modified":"2026-07-09T08:56:05","modified_gmt":"2026-07-09T03:26:05","slug":"sqlmodel-with-sqlalchemy-and-pydantic","status":"publish","type":"post","link":"https:\/\/www.guvi.in\/blog\/sqlmodel-with-sqlalchemy-and-pydantic\/","title":{"rendered":"SQLModel: Combining SQLAlchemy + Pydantic for Cleaner Code"},"content":{"rendered":"\n<p>Working with databases in Python usually means maintaining two separate sets of classes: SQLAlchemy models for the database and Pydantic schemas for validation and serialisation. They describe the same data but in two different places, and keeping them in sync adds friction to every change. SQLModel, created by the same developer behind FastAPI, solves this by merging both into one.&nbsp;<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>TL;DR\u00a0Summary<\/strong><\/h2>\n\n\n\n<ul>\n<li><strong>SQLModel combines SQLAlchemy and Pydantic into a single model layer<\/strong>, eliminating the need to maintain separate ORM and validation classes.<\/li>\n\n\n\n<li><strong>One class can handle database tables, request validation, and API serialization<\/strong>, reducing boilerplate and keeping schemas consistent across your application.<\/li>\n\n\n\n<li><strong>Built for seamless integration with FastAPI<\/strong>, SQLModel provides type safety, automatic validation, and simplified CRUD operations while retaining access to SQLAlchemy&#8217;s full power when needed.<\/li>\n<\/ul>\n\n\n\n<p><em>Simplify Python with SQLModel, combining SQLAlchemy and Pydantic for cleaner code. Master Python backend dev with HCL GUVI\u2019s <\/em><strong><em>Python Zero to Hero Course<\/em><\/strong><em>. <\/em><a href=\"https:\/\/www.guvi.in\/courses\/programming\/python-zero-to-hero\/\" target=\"_blank\" rel=\"noreferrer noopener\"><em>Start your Python journey here<\/em><\/a><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>What Is SQLModel?<\/strong><\/h2>\n\n\n\n<p>SQLModel is a Python library that lets you define a single class that works as both a SQLAlchemy ORM model and a Pydantic validation model. One class defines your table schema, validates incoming data, and serialises outgoing responses. It&#8217;s built on top of SQLAlchemy and Pydantic v2, so everything you know from both still applies.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>The Problem With Two Separate Models<\/strong><\/h2>\n\n\n\n<p>Here is what a typical FastAPI + SQLAlchemy project looks like before SQLModel:<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>SQLAlchemy ORM model<\/strong><\/h2>\n\n\n\n<p>from sqlalchemy import Column, Integer, String from database import Base<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td><strong>class<\/strong> <strong>UserORM<\/strong>(<strong>Base<\/strong>): <strong>tablename<\/strong> = &#8220;<strong>users<\/strong>&#8221; <strong>id<\/strong> = <strong>Column<\/strong>(<strong>Integer<\/strong>, <strong>primary_key<\/strong>=<strong>True<\/strong>) <strong>name<\/strong> = <strong>Column<\/strong>(<strong>String<\/strong>) <strong>email<\/strong> = <strong>Column<\/strong>(<strong>String<\/strong>, <strong>unique<\/strong>=<strong>True<\/strong>)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Pydantic schema duplicating the same fields<\/strong><\/h2>\n\n\n\n<p>from pydantic import BaseModel<\/p>\n\n\n\n<p>class UserSchema(BaseModel): id: int name: str email: str<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td><strong>class<\/strong> <strong>Config<\/strong>:<br>&nbsp; &nbsp; <strong>orm_mode<\/strong> = <strong>True<\/strong><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>Every field appears twice. Add a new column, update two files. Rename a field, update two files. The models drift apart when someone forgets to keep them in sync \u2014 and that inconsistency creates subtle bugs that are difficult to trace.<\/p>\n\n\n\n<p>SQLModel collapses this to one class.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Installing SQLModel<\/strong><\/h2>\n\n\n\n<p>pip install sqlmodel<\/p>\n\n\n\n<p>SQLModel requires <a href=\"https:\/\/www.guvi.in\/hub\/python\/\" target=\"_blank\" rel=\"noreferrer noopener\">Python <\/a>3.7+ and installs SQLAlchemy and Pydantic automatically as dependencies. No additional drivers are needed for SQLite, which is ideal for getting started.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Defining a Model<\/strong><\/h2>\n\n\n\n<ul>\n<li>from sqlmodel import SQLModel, Field from datetime import datetime<\/li>\n\n\n\n<li><strong>class User(SQLModel, table=True): id: int | None = Field(default=None, primary_key=True) name: str email: str date_joined: datetime = Field(default_factory=datetime.now) is_admin: bool = False<\/strong><\/li>\n\n\n\n<li>table=True tells SQLModel to treat this class as a database table, not just a data validation model. Each field maps directly to a column.<\/li>\n\n\n\n<li>&nbsp;The id field uses Field(default=None, primary_key=True)&nbsp; it&#8217;s optional on creation because the database generates it automatically.<\/li>\n\n\n\n<li>This single class replaces both the ORM model and the Pydantic schema. It validates input, creates the table, and serialises output. Rename a field and you only touch one file.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Creating the Database and Table<\/strong><\/h2>\n\n\n\n<ul>\n<li>from sqlmodel import SQLModel, create_engine<\/li>\n<\/ul>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>DATABASE_URL = &#8220;sqlite:\/\/\/users.db&#8221; engine = create_engine(DATABASE_URL, <strong>echo<\/strong>=<strong>True<\/strong>)<br>SQLModel.metadata.create_all(engine)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<ul>\n<li>create_engine() connects to the database. echo=True logs every SQL statement \u2014 useful during development to understand exactly what SQLModel generates. create_all() inspects every class with table=True and creates the corresponding table if it doesn&#8217;t already exist.<\/li>\n\n\n\n<li>In production, replace the SQLite URL with your <a href=\"https:\/\/www.guvi.in\/courses\/databases\/basics-of-postgresql\/\" target=\"_blank\" rel=\"noreferrer noopener\">PostgreSQL <\/a>or MySQL connection string. SQLModel supports any database backed by SQLAlchemy, including PostgreSQL, MySQL, and MariaDB.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>CRUD Operations With Sessions<\/strong><\/h2>\n\n\n\n<p>Every database operation in SQLModel goes through a session. A session batches changes in memory and commits them together more efficiently than hitting the database on every individual operation and safer in terms of transaction consistency.<\/p>\n\n\n\n<ol>\n<li><strong>Create<\/strong><\/li>\n<\/ol>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>from sqlmodel import Session<br>user = User(name=&#8221;Alice&#8221;, email=&#8221;alice@example.com&#8221;, is_admin=<strong>False<\/strong>)<br>with Session(engine) <strong>as<\/strong> session: session.add(user) session.commit() session.refresh(user) <strong>print<\/strong>(user.id) # Now has the auto-generated ID<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>session.add() stages the new user in memory. session.commit() sends the INSERT to the database. session.refresh(user) updates the Python object with the values the database generated \u2014 including the auto-incremented id.<\/p>\n\n\n\n<ol start=\"2\">\n<li><strong>Read<\/strong><\/li>\n<\/ol>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>from sqlmodel import select<br>with Session(engine) <strong>as<\/strong> session: users = session.exec(select(User)).all()<br>select(User) builds a SELECT query. session.exec() runs it. .all() returns every row <strong>as<\/strong> a <strong>list<\/strong> of User instances.<br>Filtering uses .where() with Python expressions &#8212; no SQL strings:<br>with Session(engine) <strong>as<\/strong> session: admins = session.exec( select(User).where(User.is_admin == <strong>True<\/strong>) ).all()<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>For a single row, use .first() or .one(). The difference matters: .first() returns None if nothing matches; .one() raises an exception if the result isn&#8217;t exactly one row, which makes it useful for primary key lookups where you expect a definite result.<\/p>\n\n\n\n<ol start=\"3\">\n<li><strong>Update<\/strong><\/li>\n<\/ol>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>with Session(engine) <strong>as<\/strong> session: user = session.exec(select(User).where(User.id == 1)).one() user.name = &#8220;Alice Smith&#8221; session.add(user) session.commit() session.refresh(user)<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>Select the row, modify the Python object, add it back, commit. SQLModel generates an UPDATE statement automatically. No SQL update syntax to write.<\/p>\n\n\n\n<ol start=\"4\">\n<li><strong>Delete<\/strong><\/li>\n<\/ol>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>with Session(engine) <strong>as<\/strong> session: user = session.exec(select(User).where(User.id == 1)).one() session.delete(user) session.commit()<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p>Select, delete, commit. Straightforward and readable.<\/p>\n\n\n\n<p><em>Simplify Python with SQLModel, combining SQLAlchemy and Pydantic for cleaner code. Master Python backend dev with HCL GUVI\u2019s <\/em><strong><em>Python Zero to Hero Course<\/em><\/strong><em>. <\/em><a href=\"https:\/\/www.guvi.in\/courses\/programming\/python-zero-to-hero\/\" target=\"_blank\" rel=\"noreferrer noopener\"><em>Start your Python journey here<\/em><\/a><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>SQLModel With FastAPI<\/strong><\/h2>\n\n\n\n<ol>\n<li>SQLModel was designed with FastAPI in mind. The integration is direct because both were built by the same author.<\/li>\n\n\n\n<li>from fastapi import FastAPI, Depends from sqlmodel import Session, select<\/li>\n\n\n\n<li>app = FastAPI()<\/li>\n\n\n\n<li>def get_session(): with Session(engine) as session: yield session<\/li>\n\n\n\n<li><strong>@app.post(&#8220;\/users\/&#8221;, response_model=User) def create_user(user: User, session: Session = Depends(get_session)): session.add(user) session.commit() session.refresh(user) return user<\/strong><\/li>\n\n\n\n<li><strong>@app.get(&#8220;\/users\/&#8221;, response_model=list[User]) def list_users(session: Session = Depends(get_session)): return session.exec(select(User)).all()<\/strong><\/li>\n\n\n\n<li>FastAPI uses the User class for both request body validation and response serialisation. No separate Pydantic schema is needed. The Depends(get_session) injects a database session per request automatically.<\/li>\n\n\n\n<li>One practical concern: returning the full User model exposes all fields including is_admin. In production you&#8217;d create a UserPublic model without sensitive fields. SQLModel supports schema splitting through inheritance&nbsp; see the section below.<\/li>\n<\/ol>\n\n\n\n<div style=\"background-color: #099f4e; border: 3px solid #110053; border-radius: 12px; padding: 18px 22px; color: #FFFFFF; font-size: 18px; font-family: Montserrat, Helvetica, sans-serif; line-height: 1.6; box-shadow: 0 4px 12px rgba(0, 0, 0, 0.15); max-width: 750px;\">\n\n  <strong style=\"font-size: 22px; color: #FFFFFF;\">\ud83d\udca1 Did You Know?<\/strong>\n  <br \/><br \/>\n\n  <strong style=\"color: #FFFFFF;\">SQLModel<\/strong> was created by <strong style=\"color: #FFFFFF;\">Sebasti\u00e1n Ram\u00edrez<\/strong>, the creator of <strong style=\"color: #FFFFFF;\">FastAPI<\/strong>. It was designed to eliminate the need for maintaining separate <strong style=\"color: #FFFFFF;\">SQLAlchemy ORM models<\/strong> and <strong style=\"color: #FFFFFF;\">Pydantic schemas<\/strong>. By combining data validation and database modeling into a single class, SQLModel helps developers write less code, reduce duplication, and keep their applications more consistent and easier to maintain.\n\n<\/div>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Splitting Models for Input and Output<\/strong><\/h2>\n\n\n\n<p>For real applications, you often need different views of the same data: a creation schema that excludes id, and a response schema that includes it.<\/p>\n\n\n\n<p>SQLModel supports this through inheritance:<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Shared base, no table<\/strong><\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td><strong>class<\/strong> <strong>UserBase<\/strong>(<strong>SQLModel<\/strong>): <strong>name<\/strong>: <strong>str<\/strong> <strong>email<\/strong>: <strong>str<\/strong><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Table model<\/strong><\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td><strong>class<\/strong><strong> <\/strong><strong>User<\/strong><strong>(<\/strong><strong>UserBase<\/strong><strong>, <\/strong><strong>table<\/strong><strong>=<\/strong><strong>True<\/strong><strong>): <\/strong><strong>id<\/strong><strong>: <\/strong><strong>int<\/strong><strong> | <\/strong><strong>None<\/strong><strong> = <\/strong><strong>Field<\/strong><strong>(<\/strong><strong>default<\/strong><strong>=<\/strong><strong>None<\/strong><strong>, <\/strong><strong>primary_key<\/strong><strong>=<\/strong><strong>True<\/strong><strong>) <\/strong><strong>is_admin<\/strong><strong>: <\/strong><strong>bool<\/strong><strong> = <\/strong><strong>False<\/strong><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Input schema&nbsp; no id, no is_admin<\/strong><\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td><strong>class<\/strong><strong> <\/strong><strong>UserCreate<\/strong><strong>(<\/strong><strong>UserBase<\/strong><strong>): <\/strong><strong>pass<\/strong><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>The response schema includes id<\/strong><\/h2>\n\n\n\n<ul>\n<li>class UserRead(UserBase): id: int<\/li>\n\n\n\n<li>UserBase holds the common fields. User is the database table. UserCreate is what the API accepts. UserRead is what the API returns. Each class is a thin layer that adds or excludes specific fields.<\/li>\n\n\n\n<li>This pattern keeps the model DRY, the field definitions live in one place while giving you the right shape at each layer of the API.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>SQLModel vs Raw SQL vs SQLAlchemy Alone<\/strong><\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td><strong>Approach<\/strong><\/td><td><strong>Type Safety<\/strong><\/td><td><strong>Validation<\/strong><\/td><td><strong>Boilerplate<\/strong><\/td><td><strong>Flexibility<\/strong><\/td><\/tr><tr><td>Raw SQL (sqlite3)<\/td><td>None<\/td><td>None<\/td><td>Low<\/td><td>Full<\/td><\/tr><tr><td>SQLAlchemy alone<\/td><td>Partial<\/td><td>No built-in<\/td><td>High (ORM + Pydantic)<\/td><td>Full<\/td><\/tr><tr><td>SQLModel<\/td><td>Full<\/td><td>Pydantic v2<\/td><td>Low<\/td><td>Most use cases<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<ul>\n<li>Raw SQL is the most flexible but offers no validation, no type inference, and is vulnerable to <a href=\"https:\/\/www.guvi.in\/blog\/guide-on-sql-for-data-science\/\" target=\"_blank\" rel=\"noreferrer noopener\">SQL <\/a>injection if not handled carefully.\u00a0<\/li>\n\n\n\n<li>SQLAlchemy alone is powerful but requires a separate Pydantic layer for <a href=\"https:\/\/www.guvi.in\/hub\/network-programming-with-python\/understanding-apis\/\" target=\"_blank\" rel=\"noreferrer noopener\">API <\/a>work. SQLModel covers most production use cases with minimal boilerplate and full type safety.<\/li>\n\n\n\n<li>The tradeoff: SQLModel is a higher-level abstraction. For complex queries, deeply nested joins, raw SQL performance tuning, or database-specific features, you can always drop down to SQLAlchemy directly.&nbsp;<\/li>\n\n\n\n<li>SQLModel exposes the underlying SQLAlchemy engine and session, so nothing is locked away.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Conclusion<\/strong><\/h2>\n\n\n\n<p>SQLModel removes the most tedious part of Python database work: maintaining two parallel class hierarchies that describe the same data. One class definition creates the table, validates input, and serialises output. Sessions handle batching and committing cleanly.<\/p>\n\n\n\n<p>&nbsp;The FastAPI integration is natural because both libraries share the same author and design philosophy. For new projects using FastAPI and a relational database, SQLModel is the cleanest starting point available. If you hit its limits, SQLAlchemy&#8217;s full API is always one layer beneath it.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>FAQs<\/strong><\/h2>\n\n\n<div id=\"rank-math-faq\" class=\"rank-math-block\">\n<div class=\"rank-math-list \">\n<div id=\"faq-question-1783529890971\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \"><strong>1. What is SQLModel in Python?<\/strong><\/h3>\n<div class=\"rank-math-answer \">\n\n<p>SQLModel is a Python library that combines the functionality of SQLAlchemy and Pydantic into a single model class. It allows developers to define database tables, validate data, and serialize API responses using one unified model.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-1783529896988\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \"><strong>2. Why use SQLModel instead of SQLAlchemy and Pydantic separately?<\/strong><\/h3>\n<div class=\"rank-math-answer \">\n\n<p>SQLModel reduces code duplication by eliminating the need to maintain separate ORM models and validation schemas. This makes applications easier to maintain and reduces the risk of inconsistencies between database and API models.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-1783529909844\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \"><strong>3. Is SQLModel compatible with FastAPI?<\/strong><\/h3>\n<div class=\"rank-math-answer \">\n\n<p>Yes. SQLModel was designed to work seamlessly with FastAPI. The same model can be used for request validation, database operations, and response serialization, significantly reducing development effort.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-1783529919754\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \"><strong>4. Does SQLModel replace SQLAlchemy?<\/strong><\/h3>\n<div class=\"rank-math-answer \">\n\n<p>Not entirely. SQLModel is built on top of SQLAlchemy and uses its ORM capabilities internally. Developers can still access SQLAlchemy&#8217;s underlying engine, session management, and advanced query features whenever needed.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-1783529927822\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \"><strong>5. How does SQLModel handle CRUD operations?<\/strong><\/h3>\n<div class=\"rank-math-answer \">\n\n<p>SQLModel uses SQLAlchemy-style sessions for database interactions. Developers can create, read, update, and delete records using familiar session-based workflows while benefiting from Python type hints and automatic validation.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-1783529935758\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \"><strong>6. Can SQLModel be used with databases other than SQLite?<\/strong><\/h3>\n<div class=\"rank-math-answer \">\n\n<p>Yes. SQLModel supports any database compatible with SQLAlchemy, including PostgreSQL, MySQL, and MariaDB, in addition to SQLite.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-1783529946058\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \"><strong>7. Should I create separate models for API input and output?<\/strong><\/h3>\n<div class=\"rank-math-answer \">\n\n<p>Yes, for production applications. While a single SQLModel class can handle multiple roles, creating specialized models such as UserCreate and UserRead helps prevent exposing sensitive fields and provides better control over API behavior.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-1783529958139\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \"><strong>8. What are the advantages of SQLModel over raw SQL?<\/strong><\/h3>\n<div class=\"rank-math-answer \">\n\n<p>SQLModel provides type safety, automatic validation, ORM functionality, and cleaner code while reducing the risk of SQL injection and schema inconsistencies. Raw SQL offers more flexibility but requires significantly more manual work and validation.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-1783529969088\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \"><strong>9. Are there situations where SQLModel may not be the best choice?<\/strong><\/h3>\n<div class=\"rank-math-answer \">\n\n<p>For highly complex database operations, advanced query optimization, database-specific features, or extensive custom ORM behavior, developers may need to work directly with SQLAlchemy&#8217;s lower-level APIs.<\/p>\n\n<\/div>\n<\/div>\n<div id=\"faq-question-1783529979161\" class=\"rank-math-list-item\">\n<h3 class=\"rank-math-question \"><strong>10. Is SQLModel suitable for production applications?<\/strong><\/h3>\n<div class=\"rank-math-answer \">\n\n<p>Yes. SQLModel is well-suited for production applications, especially those built with FastAPI. It provides strong type safety, streamlined development workflows, and access to SQLAlchemy&#8217;s mature database ecosystem when advanced functionality is required.<\/p>\n\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Working with databases in Python usually means maintaining two separate sets of classes: SQLAlchemy models for the database and Pydantic schemas for validation and serialisation. They describe the same data but in two different places, and keeping them in sync adds friction to every change. SQLModel, created by the same developer behind FastAPI, solves this [&hellip;]<\/p>\n","protected":false},"author":63,"featured_media":122123,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[717],"tags":[],"views":"27","authorinfo":{"name":"Vishalini Devarajan","url":"https:\/\/www.guvi.in\/blog\/author\/vishalini\/"},"thumbnailURL":"https:\/\/www.guvi.in\/blog\/wp-content\/uploads\/2026\/07\/sqlmodel-with-sqlalchemy-and-pydantic-300x118.webp","_links":{"self":[{"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/posts\/122077"}],"collection":[{"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/users\/63"}],"replies":[{"embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/comments?post=122077"}],"version-history":[{"count":4,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/posts\/122077\/revisions"}],"predecessor-version":[{"id":122154,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/posts\/122077\/revisions\/122154"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/media\/122123"}],"wp:attachment":[{"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/media?parent=122077"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/categories?post=122077"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.guvi.in\/blog\/wp-json\/wp\/v2\/tags?post=122077"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}