{"id":20,"date":"2026-08-05T03:47:01","date_gmt":"2026-08-05T03:47:01","guid":{"rendered":""},"modified":"2026-08-05T03:47:01","modified_gmt":"2026-08-05T03:47:01","slug":"evaluating-sql-database-suitability-for-ai-workloads_-a-framework-for-vector-search-hybrid-querying-and-tco-trade-offs","status":"publish","type":"post","link":"https:\/\/47.250.123.25\/blog\/tech-blog\/evaluating-sql-database-suitability-for-ai-workloads_-a-framework-for-vector-search-hybrid-querying-and-tco-trade-offs\/","title":{"rendered":"Evaluating SQL Database Suitability for AI Workloads_ A Framework for Vector Search, Hybrid Querying, and TCO Trade-offs"},"content":{"rendered":"<p><img decoding=\"async\" src=\"https:\/\/kingbase-bbs.oss-cn-beijing.aliyuncs.com\/qywx\/blogImage\/8a710c3f-1b71-43e7-81f7-4530573e65c0.png\" alt=\"Abstract illustration of a unified SQL database architecture integrating transactional records and vector search layers.\" \/><\/p>\n<h2>The Architectural Chasm: Transactional Records vs. Vector Retrieval Layers<\/h2>\n<p>The marketing narrative surrounding &quot;AI-ready databases&quot; often obscures a fundamental architectural tension: the conflict between the strict, row-oriented integrity required for transactional systems (ACID) and the high-throughput, approximate nearest-neighbor (ANN) search patterns required for vector retrieval. For enterprise architects planning to integrate Retrieval-Augmented Generation (RAG) or semantic search into existing SQL infrastructure, the primary challenge is not merely adding a feature, but reconciling two distinct data access patterns within a single engine.<\/p>\n<p>When evaluating a <strong>sql database for ai applications<\/strong>, it is critical to distinguish between &quot;AI for SQL&quot; (external agents generating queries) and &quot;AI-Enhanced SQL&quot; (native storage and retrieval of vector embeddings). The risk of conflating these concepts leads to architectural debt, where a unified system becomes a bottleneck for both transactional throughput and vector latency.<\/p>\n<p>KingbaseES is a commercial SQL database that functions as a system of record, but its AI capabilities must be verified against specific version documentation. Its suitability for AI workloads depends on whether it can physically coexist with vector indexing mechanisms without degrading the performance of core business transactions. The database must support distinct storage engines: traditional B-Tree or similar structures for row data, and specialized indexes for vector similarity search. Without clear documentation on how these structures interact under load, the assumption that a single engine can handle both workloads efficiently remains unproven.<\/p>\n<p>The evaluation framework below does not assume native AI capabilities exist in every version or configuration. Instead, it establishes the criteria for verifying that the underlying storage engine can sustain the I\/O patterns of high-dimensional vector data alongside standard relational operations.<\/p>\n<h2>Decoding the &quot;Native&quot; Claim: Extensions, Versions, and Algorithmic Reality<\/h2>\n<p>The term &quot;native&quot; in database marketing is frequently ambiguous. It may refer to a proprietary extension, a specific version upgrade, or a third-party library wrapped within the database kernel. For a commercial product like KingbaseES, the presence of vector search capabilities is a licensed feature dependent on specific versioning and configuration.<\/p>\n<p>To validate whether a <strong>sql database for ai applications<\/strong> can support your workload, architects must audit the following technical implementation details:<\/p>\n<ul>\n<li><strong>Indexing Algorithm Support<\/strong>: Does the engine support specific algorithms such as HNSW (Hierarchical Navigational Small World) or IVF (Inverted File Index)? These algorithms determine the trade-off between search speed and memory consumption.<\/li>\n<li><strong>Version Specificity<\/strong>: Is the vector capability enabled by default, or does it require a specific patch or enterprise edition?<\/li>\n<li><strong>Extension Overhead<\/strong>: Is the vector functionality a lightweight extension, or does it introduce significant overhead to the query planner?<\/li>\n<\/ul>\n<p>A checklist for verifying the technical baseline includes:<\/p>\n<table>\n<thead>\n<tr>\n<th style=\"text-align:left\">Verification Item<\/th>\n<th style=\"text-align:left\">Requirement for AI Suitability<\/th>\n<th style=\"text-align:left\">Evidence Source Required<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td style=\"text-align:left\"><strong>Index Type<\/strong><\/td>\n<td style=\"text-align:left\">Must support the specific algorithm (e.g., HNSW or IVF) required for high-dimensional vectors.<\/td>\n<td style=\"text-align:left\">Vendor documentation or release notes.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align:left\"><strong>Vector Dimension<\/strong><\/td>\n<td style=\"text-align:left\">Must support the specific dimension size of your embedding model.<\/td>\n<td style=\"text-align:left\">Product specification sheet.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align:left\"><strong>Update Mechanism<\/strong><\/td>\n<td style=\"text-align:left\">Must support dynamic index updates without full table re-indexing.<\/td>\n<td style=\"text-align:left\">Technical whitepaper or architecture guide.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align:left\"><strong>Configuration<\/strong><\/td>\n<td style=\"text-align:left\">Must allow tuning of algorithm-specific parameters (e.g., connectivity, construction efficiency).<\/td>\n<td style=\"text-align:left\">Configuration reference manual.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>If the evidence for these specific parameters is absent, the database cannot be assumed to support production-grade vector workloads. The absence of a mapped feature in the evidence package requires the architect to treat the claim as a verification question rather than a capability.<\/p>\n<h2>Hybrid Search Latency: Measuring the Cost of Metadata Filtering<\/h2>\n<p>The true test of a <strong>sql database for ai applications<\/strong> is not pure vector similarity search, but hybrid search: combining vector similarity with metadata filtering (e.g., &quot;find documents similar to this query <em>where<\/em> <code>department_id = 101<\/code> and <code>date &gt; 2023-01-01<\/code>&quot;).<\/p>\n<p>In a dedicated vector database, filtering is often optimized separately. In a unified SQL environment, the query planner must join the vector index with the relational index. This introduces a latency cost that scales with the cardinality of the filters.<\/p>\n<p>To evaluate this, architects must measure latency of hybrid queries under varying filter constraints. The following table outlines the metrics required to assess performance against organization-specific SLAs:<\/p>\n<table>\n<thead>\n<tr>\n<th style=\"text-align:left\">Metric<\/th>\n<th style=\"text-align:left\">Description<\/th>\n<th style=\"text-align:left\">Example Targets (For Framework)<\/th>\n<th style=\"text-align:left\">Validation Method<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td style=\"text-align:left\"><strong>Pure Vector Latency<\/strong><\/td>\n<td style=\"text-align:left\">Time to find top-K vectors without filters.<\/td>\n<td style=\"text-align:left\">Industry-standard targets (e.g., &lt; 10ms)<\/td>\n<td style=\"text-align:left\">Load test with representative vector count.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align:left\"><strong>Hybrid Latency (High Cardinality)<\/strong><\/td>\n<td style=\"text-align:left\">Latency with multiple distinct filter predicates.<\/td>\n<td style=\"text-align:left\">Organization-specific SLAs<\/td>\n<td style=\"text-align:left\">Stress test with complex WHERE clauses.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align:left\"><strong>Throughput Degradation<\/strong><\/td>\n<td style=\"text-align:left\">% drop in TPS when switching from pure to hybrid queries.<\/td>\n<td style=\"text-align:left\">Organization-specific thresholds<\/td>\n<td style=\"text-align:left\">Concurrent workload simulation.<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align:left\"><strong>Filter Cardinality Impact<\/strong><\/td>\n<td style=\"text-align:left\">Latency increase per additional filter.<\/td>\n<td style=\"text-align:left\">Linear or sub-linear growth<\/td>\n<td style=\"text-align:left\">Varying filter count.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p><em>Note: The values in the &quot;Example Targets&quot; column are hypothetical examples for the evaluation framework. Actual KingbaseES performance must be validated against the user&#8217;s specific workload.<\/em><\/p>\n<p>If the database cannot demonstrate sub-linear latency growth as filters are added, the unified architecture may become a bottleneck for real-time RAG applications. The evidence for these metrics must be derived from controlled benchmarks that replicate the specific data distribution of the enterprise, rather than generic vendor claims.<\/p>\n<h2>The TCO Trap: Unified Architecture vs. Polyglot Persistence<\/h2>\n<p>Adopting a unified architecture\u2014storing both transactional data and vector embeddings in a single <strong>sql database for ai applications<\/strong>\u2014is often driven by the desire to reduce operational complexity. However, the Total Cost of Ownership (TCO) analysis must account for more than just licensing fees.<\/p>\n<p>The decision to unify or split the architecture depends on the following variables:<\/p>\n<ol>\n<li><strong>Licensing Costs<\/strong>: Commercial databases often charge based on core count or data volume. Vector indexing can significantly increase memory and CPU requirements, potentially pushing the system into a higher licensing tier.<\/li>\n<li><strong>Compute Contention<\/strong>: Vector search is CPU and memory-intensive. Running it alongside transactional workloads on the same hardware can lead to resource contention, requiring over-provisioning of resources to maintain SLAs.<\/li>\n<li><strong>Operational Complexity<\/strong>: While a single engine simplifies backup and recovery, it complicates tuning. The DBA must balance vector index parameters against transactional lock contention.<\/li>\n<li><strong>Scaling Strategy<\/strong>: If the vector dataset grows significantly, a unified SQL database may require expensive hardware upgrades, whereas a polyglot approach allows scaling the vector store independently.<\/li>\n<\/ol>\n<p><strong>Steps to Calculate TCO:<\/strong><\/p>\n<ol>\n<li><strong>Baseline Resource Usage<\/strong>: Measure current CPU, memory, and I\/O for transactional workloads.<\/li>\n<li><strong>Vector Load Simulation<\/strong>: Run a simulated vector workload to determine the additional resource footprint.<\/li>\n<li><strong>Licensing Impact<\/strong>: Calculate the cost increase if the new resource footprint triggers a higher license tier.<\/li>\n<li><strong>Operational Overhead<\/strong>: Estimate the DBA hours required to tune the unified system versus managing two separate systems.<\/li>\n<li><strong>Risk Cost<\/strong>: Factor in the potential cost of performance degradation if the unified system fails to meet latency SLAs.<\/li>\n<\/ol>\n<p>If the TCO of the unified approach exceeds the cost of a split architecture by a significant margin, the decision to unify should be reconsidered unless the operational simplicity provides a specific business advantage. The specific threshold for this comparison must be determined by the organization&#8217;s financial constraints and operational priorities.<\/p>\n<h2>Security and Governance: Auditing AI-Generated Data in a Unified System<\/h2>\n<p>In a unified environment, AI-generated embeddings and sensitive source data often reside in the same table. This raises critical governance questions regarding access control and data integrity.<\/p>\n<p>A robust <strong>sql database for ai applications<\/strong> must enforce Row-Level Security (RLS) and Role-Based Access Control (RBAC) consistently across both relational and vector columns. If an AI agent generates an embedding for a customer record, the database must ensure that only authorized users can query that specific vector or view the associated metadata.<\/p>\n<p><strong>Pseudocode for Illustration:<\/strong><\/p>\n<pre><code class=\"language-sql\">-- Pseudocode: Enforcing Row-Level Security on a table with vector columns\n-- This example illustrates the logic required. Actual implementation depends on KingbaseES's specific RLS syntax.\n-- The specific functions used below (e.g., user_has_access_to_department) are hypothetical and must be verified in documentation.\n\nCREATE POLICY ai_access_policy ON documents\nFOR SELECT\nUSING (\n    -- Check if the user has access to the source record\n    user_has_access_to_department(department_id)\n    AND -- Additional check for vector visibility if needed\n    is_vector_accessible(current_user)\n);\n<\/code><\/pre>\n<p>Key governance requirements include:<\/p>\n<ul>\n<li><strong>Audit Logging<\/strong>: Every query that retrieves a vector embedding must be logged, including the query parameters and the user identity.<\/li>\n<li><strong>Encryption at Rest<\/strong>: Vector data, like any other sensitive data, must be encrypted. The encryption mechanism must not significantly degrade search performance. <em>Note: Specific support for encrypting vector columns without performance degradation must be verified in KingbaseES documentation.<\/em><\/li>\n<li><strong>Data Lineage<\/strong>: The database must support metadata tracking to link the vector embedding back to the source document and the AI model version used to generate it.<\/li>\n<\/ul>\n<p>Without these controls, the unified architecture introduces a risk of data leakage where an AI agent could inadvertently expose sensitive information through vector similarity searches.<\/p>\n<h2>The Validation Protocol: A Baseline-First Framework for Deployment<\/h2>\n<p>Before committing to a specific <strong>sql database for ai applications<\/strong>, architects must execute a validation protocol. This process separates observed evidence from projected value, ensuring that the chosen solution meets the specific constraints of the enterprise.<\/p>\n<p><strong>Step-by-Step Evaluation Protocol:<\/strong><\/p>\n<ol>\n<li><strong>Define the Baseline<\/strong>: Establish the current performance metrics for the existing transactional system (TPS, latency) and the target AI workload (vector dimension, dataset size).<\/li>\n<li><strong>Select the Test Dataset<\/strong>: Use a representative subset of production data that includes the full range of metadata attributes and vector dimensions.<\/li>\n<li><strong>Configure the Index<\/strong>: Set up the vector index with parameters based on the vendor&#8217;s documentation.<\/li>\n<li><strong>Run Pure Vector Tests<\/strong>: Measure latency and recall for pure similarity searches.<\/li>\n<li><strong>Run Hybrid Tests<\/strong>: Introduce metadata filters and measure the latency impact.<\/li>\n<li><strong>Stress Test<\/strong>: Simulate concurrent transactional and vector queries to identify resource contention points.<\/li>\n<li><strong>Analyze Results<\/strong>: Compare the results against the baseline and the SLA requirements.\n<ul>\n<li><em>Evaluation Threshold<\/em>: If hybrid latency exceeds the SLA or if transactional TPS drops beyond the organization&#8217;s defined tolerance, the unified approach may not be viable.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Document Limitations<\/strong>: Record any observed limitations, such as index rebuild times or memory spikes, to inform the final deployment strategy.<\/li>\n<\/ol>\n<p><em>Disclaimer: The specific metrics (latency, TPS) mentioned in this protocol are hypothetical examples for the framework. Actual KingbaseES performance must be validated against the user&#8217;s specific workload.<\/em><\/p>\n<p>This protocol ensures that the decision is based on empirical data rather than marketing claims. If the evidence does not support the unified approach, the architect should consider a polyglot persistence model.<\/p>\n<h2>The Malaysian Context<\/h2>\n<p>Architects operating in Malaysia must address specific regulatory and operational considerations. <strong>No evidence is currently mapped regarding KingbaseES&#8217;s local Malaysian data centers, PDPA compliance certifications, or local support SLAs. Architects must verify these with the vendor.<\/strong><\/p>\n<p>While Malaysia&#8217;s Personal Data Protection Act (PDPA) governs data handling, it does not create a blanket data-residency mandate for all data types. However, specific industry regulations or customer contracts may impose stricter data residency requirements. Organizations must verify if KingbaseES can meet these specific local compliance needs, including the availability of local engineering support and response times.<\/p>\n<h2>Evidence Gaps for KingbaseES<\/h2>\n<p>The following data points are currently missing from the evidence package and require verification before deployment:<\/p>\n<ul>\n<li><strong>Vector Indexing Algorithms<\/strong>: No evidence mapped confirming support for specific algorithms (HNSW\/IVF) or their configuration parameters (e.g., <code>m<\/code>, <code>ef_construction<\/code>).<\/li>\n<li><strong>Version Requirements<\/strong>: No evidence mapped regarding specific version requirements for vector features.<\/li>\n<li><strong>Licensing Models<\/strong>: No evidence mapped regarding licensing cost models relative to vector workloads.<\/li>\n<li><strong>Encryption Capabilities<\/strong>: No evidence mapped regarding encryption support specifically for vector columns and associated performance impact.<\/li>\n<li><strong>RLS Implementation<\/strong>: No evidence mapped regarding specific RLS function availability or syntax for vector columns.<\/li>\n<li><strong>Performance Metrics<\/strong>: No evidence mapped for specific performance metrics (latency, throughput) for KingbaseES under vector workloads.<\/li>\n<li><strong>Malaysian Presence<\/strong>: No evidence mapped for local data centers, support SLAs, or engineering availability in Malaysia.<\/li>\n<li><strong>TCO Thresholds<\/strong>: No evidence mapped for specific TCO thresholds (e.g., 20% cost increase) or TPS drop tolerances.<\/li>\n<\/ul>\n<h2>Conclusion: A Decision Framework for AI-Ready SQL<\/h2>\n<p>The suitability of a commercial SQL database like KingbaseES for AI workloads is not a binary &quot;yes&quot; or &quot;no&quot; but a function of specific workload characteristics and architectural constraints. The decision to extend an existing SQL environment for AI applications should be guided by the evidence gathered during the validation protocol.<\/p>\n<p><strong>When to Extend the SQL Environment:<\/strong><\/p>\n<ul>\n<li><strong>Moderate Scale<\/strong>: Vector datasets are within a manageable size for the specific hardware configuration.<\/li>\n<li><strong>Strict ACID Requirements<\/strong>: Transactional integrity is the primary concern, and vector search is secondary.<\/li>\n<li><strong>Unified Governance<\/strong>: The organization requires a single point of control for security, auditing, and compliance.<\/li>\n<li><strong>Proven Performance<\/strong>: The validation protocol demonstrates that hybrid search latency meets SLA requirements without degrading transactional performance.<\/li>\n<\/ul>\n<p><strong>When to Adopt a Separate Vector Layer:<\/strong><\/p>\n<ul>\n<li><strong>Massive Scale<\/strong>: Vector datasets require extreme query concurrency or storage sizes that exceed the unified engine&#8217;s capacity.<\/li>\n<li><strong>Extreme Latency Sensitivity<\/strong>: The application requires sub-millisecond latency for vector search that cannot be met by a unified engine.<\/li>\n<li><strong>Specialized Algorithms<\/strong>: The workload requires vector algorithms not supported by the SQL database&#8217;s native extensions.<\/li>\n<li><strong>Resource Isolation<\/strong>: The organization needs to scale compute and memory for vector workloads independently of the transactional layer.<\/li>\n<\/ul>\n<p>The &quot;Value-Proof&quot; of a <strong>sql database for ai applications<\/strong> lies not in the marketing label, but in the measured performance against the specific baseline defined by the enterprise. By adhering to a rigorous evaluation framework, architects can make informed decisions that balance innovation with operational stability.<\/p>\n<h2>FAQ<\/h2>\n<h3>How do I distinguish between an AI tool that writes SQL and a database with native AI vector capabilities?<\/h3>\n<p>An AI tool that writes SQL (e.g., a Text-to-SQL agent) sits <em>outside<\/em> the database and generates queries based on natural language. A database with native AI vector capabilities has internal mechanisms to store, index, and retrieve high-dimensional vector embeddings directly within the storage engine. The former requires an external orchestration layer, while the latter integrates the retrieval logic into the database kernel.<\/p>\n<h3>What are the specific risks of using a single SQL database for both transactional data and vector embeddings?<\/h3>\n<p>The primary risks are performance contention and architectural complexity. Vector search is memory and CPU-intensive, which can degrade transactional throughput. Additionally, tuning the database for both workloads simultaneously is complex, and a failure in the vector index could potentially impact the stability of the entire transactional system if not properly isolated.<\/p>\n<h3>How can I validate the accuracy of AI-generated queries before executing them in a production environment?<\/h3>\n<p>Validation requires a &quot;guardrail&quot; approach. AI-generated SQL should first be executed in a read-only sandbox environment or against a copy of the production data. Automated testing frameworks can compare the results of the AI-generated query against known correct results (ground truth). Human-in-the-loop review should be mandatory for any query involving data modification (INSERT, UPDATE, DELETE).<\/p>\n<h3>Does a commercial SQL database like KingbaseES replace the need for an external orchestration layer in RAG architectures?<\/h3>\n<p>No. Even if a SQL database supports native vector storage, a RAG architecture typically requires an orchestration layer to manage the lifecycle of documents, generate embeddings, handle context window management, and coordinate the interaction between the LLM, the vector store, and the source data. The database serves as the storage and retrieval layer, not the orchestration logic.<\/p>\n<h3>What are the primary limitations of current LLMs when handling complex multi-table joins within SQL generation?<\/h3>\n<p>Current LLMs often struggle with complex multi-table joins, especially when the schema is large or the relationships are non-intuitive. They may hallucinate column names, miss necessary join conditions, or generate inefficient query plans. This risk necessitates a validation layer and limits the reliability of fully automated SQL generation for complex enterprise schemas.<\/p>\n<hr \/>\n<p><strong>&#128161; More Resources<\/strong><\/p>\n<p>If you would like to dive deeper into KingbaseES and its application practices across various industries, we have compiled the following official resources to help you get started quickly and develop and operate with efficiency:<\/p>\n<ul>\n<li><a href=\"https:\/\/bbs.kingbase.com.cn\/\">Kingbase Community<\/a>: A one-stop interactive platform for technical exchanges, Q&#038;A, and experience sharing&mdash;join forces with fellow DBAs and developers.<\/li>\n<li><a href=\"https:\/\/www.kingbaseglobal.com\/Solution-Oracle.html\">Kingbase Solutions<\/a>: One-stop full-stack database migration and cloud-native solutions, supporting smooth migration of multi-source heterogeneous data, ensuring high availability, real-time integration, and sustained high performance.<\/li>\n<li><a href=\"https:\/\/www.kingbaseglobal.com\/Customers.html\">Kingbase Case Studies<\/a>: Real-world user scenarios and implementation outcomes, showcasing KingbaseES&#8217;s outstanding capabilities in high availability, high performance, and IT adaptation.<\/li>\n<li><a href=\"https:\/\/docs.kingbase.com.cn\/en\">Kingbase Documentation<\/a>: Authoritative and comprehensive product manuals and technical guides, covering the entire lifecycle from installation and deployment to development, programming, and operations management.<\/li>\n<li><a href=\"https:\/\/www.kingbaseglobal.com\/Download.html\">Free Download<\/a>: Get the latest installation packages, drivers, tools, and patches, supporting multiple platforms and domestic chip architectures.<\/li>\n<li><a href=\"https:\/\/www.kingbaseglobal.com\/blog\/\">Digital Construction Encyclopedia<\/a>: Covers digital strategy planning, data integration, metrics management, database visualization applications, and more to empower enterprise digital transformation.<\/li>\n<\/ul>\n<p><strong>Open Source Resources:<\/strong><\/p>\n<ul>\n<li><a href=\"https:\/\/github.com\/hgsandy\/Kingbase-docs\">GitHub &#8211; Kingbase-docs<\/a>: Kingbase documentation open-source repository&mdash;Stars and contributions are welcome.<\/li>\n<li><a href=\"https:\/\/gitee.com\/hgsandy\/kingbase-docs\">Gitee &#8211; Kingbase-docs<\/a>: Domestic mirror repository for Kingbase documentation for faster access.<\/li>\n<\/ul>\n<p>Welcome to explore the resources above and begin your Kingbase journey!<\/p>\n","protected":false},"excerpt":{"rendered":"<p>The Architectural Chasm: Transactional Records vs. Vector Retrieval Layers The marketing narrative surrounding &quot;AI-ready databases&quot; often obscures a fundamental architectural tension: the conflict between the strict, row-oriented integrity required for&#8230;<\/p>\n","protected":false},"author":195,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-20","post","type-post","status-publish","format-standard","hentry"],"_links":{"self":[{"href":"https:\/\/47.250.123.25\/blog\/wp-json\/wp\/v2\/posts\/20","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/47.250.123.25\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/47.250.123.25\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/47.250.123.25\/blog\/wp-json\/wp\/v2\/users\/195"}],"replies":[{"embeddable":true,"href":"https:\/\/47.250.123.25\/blog\/wp-json\/wp\/v2\/comments?post=20"}],"version-history":[{"count":0,"href":"https:\/\/47.250.123.25\/blog\/wp-json\/wp\/v2\/posts\/20\/revisions"}],"wp:attachment":[{"href":"https:\/\/47.250.123.25\/blog\/wp-json\/wp\/v2\/media?parent=20"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/47.250.123.25\/blog\/wp-json\/wp\/v2\/categories?post=20"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/47.250.123.25\/blog\/wp-json\/wp\/v2\/tags?post=20"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}