{"id":8739,"date":"2026-07-30T09:00:45","date_gmt":"2026-07-30T12:00:45","guid":{"rendered":"https:\/\/powertuning.com.br\/blog\/?p=8739"},"modified":"2026-07-31T14:01:35","modified_gmt":"2026-07-31T17:01:35","slug":"de-sql-server-para-postgresql-instancia-database-e-schema-onde-cada-coisa-mora","status":"publish","type":"post","link":"https:\/\/powertuning.com.br\/blog\/de-sql-server-para-postgresql-instancia-database-e-schema-onde-cada-coisa-mora\/","title":{"rendered":"De SQL Server para PostgreSQL #02 – Inst\u00e2ncia, database e schema. Onde cada coisa mora."},"content":{"rendered":"

 <\/p>\n

\n
\n

SQL Server e PostgreSQL organizam inst\u00e2ncia, database e schema de formas estruturalmente diferentes \u2014 e essa diferen\u00e7a muda completamente como uma query cruza dados entre bancos em cada um.<\/p>\n

Francisco Porf\u00edrio<\/span> \u00b7 Time PostgreSQL da Power Tuning<\/p>\n<\/div>\n

Na primeira postagem desta s\u00e9rie<\/a>, falamos sobre o primeiro choque de quem sai do wizard do SQL Server no Windows para o apt install<\/code>\/initdb<\/code> do Linux. Resolvida a instala\u00e7\u00e3o, o segundo estranhamento normalmente aparece j\u00e1 no primeiro dia de uso, na primeira vez que algu\u00e9m tenta fazer um JOIN<\/code> entre duas bases diferentes no mesmo servidor.<\/p>\n

No SQL Server, a resposta usa nomea\u00e7\u00e3o de tr\u00eas partes, banco.schema.objeto<\/code>, dentro da mesma inst\u00e2ncia. No Postgres, a resposta segue outro caminho, porque a arquitetura \u00e9 diferente: cada database \u00e9 uma unidade isolada, com cat\u00e1logo e visibilidade de transa\u00e7\u00e3o pr\u00f3prios.<\/p>\n

Este post organiza a hierarquia inst\u00e2ncia \u2192 database \u2192 schema nos dois bancos, mostra onde cada coisa mora fisicamente em disco, e explica por que uma cross-database query segue caminhos diferentes em cada um \u2014 e o que isso muda na pr\u00e1tica, na hora de cruzar dados entre databases.<\/p>\n

\n\n\n\n
\n

SQL Server (Inst\u00e2ncia)<\/p>\n

\n

1 inst\u00e2ncia = 1 processo\/servi\u00e7o<\/p>\n\n\n\n
BancoA<\/span>schema: dbo<\/span>Clientes<\/span><\/td>\nBancoB<\/span>schema: dbo<\/span>Pedidos<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

\u2194 Refer\u00eancia direta entre bancos<\/p>\n

BancoA.dbo.Clientes c<\/p>\n

JOIN BancoB.dbo.Pedidos p<\/p>\n

Cat\u00e1logo compartilhado<\/p>\n<\/div>\n

1 conex\u00e3o<\/span>enxerga BancoA e BancoB<\/span><\/div>\n<\/td>\n
\n

PostgreSQL (Cluster)<\/p>\n

\n

1 cluster = 1 processo\/servi\u00e7o<\/p>\n\n\n\n
bancoa<\/span>schema: public<\/span>clientes<\/span><\/td>\nbancob<\/span>schema: public<\/span>pedidos<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

\u00d7<\/p>\n

Isto n\u00e3o roda no Postgres:<\/p>\n

bancoa.public.clientes c<\/p>\n

JOIN bancob.public.pedidos p<\/p>\n

S\u00f3 \u00e9 poss\u00edvel via postgres_fdw<\/p>\n<\/div>\n\n\n\n
Conex\u00e3o 1<\/span>s\u00f3 v\u00ea bancoa<\/span><\/td>\nConex\u00e3o 2<\/span>s\u00f3 v\u00ea bancob<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

No SQL Server, todos os databases da inst\u00e2ncia s\u00e3o geridos pelo mesmo processo\/engine, que acessa o cat\u00e1logo de cada um simultaneamente \u2014 por isso permite refer\u00eancia direta entre eles.<\/p>\n

No Postgres, um JOIN direto entre bancoa e bancob n\u00e3o existe: \u00e9 preciso importar a tabela via postgres_fdw antes.<\/p>

Hierarquia inst\u00e2ncia\/cluster \u2192 database \u2192 schema: SQL Server x PostgreSQL<\/figcaption><\/figure>\n

Como o SQL Server te acostumou a pensar<\/h2>\n

Uma inst\u00e2ncia do SQL Server \u00e9 um \u00fanico processo (o servi\u00e7o MSSQLSERVER<\/code> ou uma inst\u00e2ncia nomeada) que hospeda v\u00e1rios databases<\/strong> ao mesmo tempo, todos vis\u00edveis pela mesma conex\u00e3o. Dentro de cada database existem um ou mais schemas (o padr\u00e3o sendo dbo<\/code>), e dentro de cada schema, os objetos: tabelas, views, procedures.<\/p>\n

A nomea\u00e7\u00e3o de tr\u00eas partes deixa isso natural no dia a dia:<\/p>\n

-- Uma \u00fanica conex\u00e3o referenciando dois databases diferentes\r\nSELECT c.nome, p.valor\r\nFROM BancoA.dbo.Clientes c\r\nJOIN BancoB.dbo.Pedidos p ON p.cliente_id = c.id\r\nWHERE c.ativo = 1;<\/code><\/span><\/pre>\n
Isso funciona porque, dentro de uma inst\u00e2ncia no SQL Server, cada database mant\u00e9m seu pr\u00f3prio cat\u00e1logo de metadados \u2014 mas todos s\u00e3o geridos pelo mesmo processo (MSSQLSERVER), que tamb\u00e9m administra um gerenciador de locks\/transa\u00e7\u00f5es comum a todos eles. O USE<\/code> apenas troca o database “padr\u00e3o” de contexto para nomes sem prefixo \u2014 mas qualquer objeto de qualquer outro database da mesma inst\u00e2ncia continua acess\u00edvel via nome completo, porque o engine consegue abrir e resolver o cat\u00e1logo daquele database durante a compila\u00e7\u00e3o da query, montando um \u00fanico plano de execu\u00e7\u00e3o, na mesma transa\u00e7\u00e3o.<\/p>\n
A filosofia do Postgres: cada database \u00e9 um cofre isolado<\/h2>\n
Lembra do “cluster” que criamos no post anterior com o initdb<\/code>? Esse \u00e9 o equivalente mais pr\u00f3ximo de uma inst\u00e2ncia: um \u00fanico processo postgres<\/code>, ouvindo em uma porta, capaz de hospedar m\u00faltiplos databases. At\u00e9 aqui, parecido com o SQL Server.<\/p>\n
A diferen\u00e7a aparece na camada de baixo: no Postgres, cada database tem seu pr\u00f3prio cat\u00e1logo de sistema<\/strong> (as tabelas internas que descrevem tabelas, colunas, \u00edndices, permiss\u00f5es etc.) e sua pr\u00f3pria visibilidade de transa\u00e7\u00f5es (MVCC). Fisicamente, cada database vive em um diret\u00f3rio separado dentro do cluster:<\/p>\n
# Cada subdiret\u00f3rio num\u00e9rico \u00e9 um database, identificado pelo OID\r\n\/var\/lib\/postgresql\/18\/main\/base\/16384\/   # bancoa\r\n\/var\/lib\/postgresql\/18\/main\/base\/16391\/   # bancob<\/code><\/span><\/pre>\n
E, consequ\u00eancia direta disso: uma conex\u00e3o no Postgres se autentica em um \u00fanico database por vez<\/strong>. N\u00e3o existe um USE outrobanco;<\/code> que troque o contexto dentro da mesma sess\u00e3o \u2014 trocar de database significa abrir uma nova conex\u00e3o. No psql<\/code>, o comando mais pr\u00f3ximo disso \u00e9 \\c<\/code> \u2014 mas por baixo dos panos ele fecha a conex\u00e3o atual e abre outra.<\/p>\n
postgres=# \\c bancoa\r\nYou are now connected to database \"bancoa\" as user \"postgres\".\r\n-- \\c n\u00e3o \"troca de contexto\": \u00e9 uma reconex\u00e3o de verdade<\/code><\/span><\/pre>\n
\n
E se eu tentar mesmo assim?<\/strong> O Postgres nem deixa passar pelo parser. Tentar referenciar um database no nome do objeto retorna um erro bem direto ao ponto: ERROR: cross-database references are not implemented<\/code>. N\u00e3o \u00e9 uma permiss\u00e3o faltando, \u00e9 a arquitetura dizendo que aquele caminho n\u00e3o existe.<\/p>\n<\/div>\n
Onde entra o schema<\/h2>\n
Dentro de cada database, o Postgres tamb\u00e9m organiza objetos em schemas \u2014 o conceito em si \u00e9 id\u00eantico ao do SQL Server. A diferen\u00e7a \u00e9 s\u00f3 o nome do padr\u00e3o: em vez de dbo<\/code>, todo database novo j\u00e1 nasce com um schema chamado public<\/code>.<\/p>\n
A nomea\u00e7\u00e3o de objetos no Postgres \u00e9, portanto, de duas partes<\/strong>, n\u00e3o tr\u00eas: schema.objeto<\/code>. O database nunca entra no nome, porque ele j\u00e1 est\u00e1 impl\u00edcito na conex\u00e3o atual:<\/p>\n
-- Funciona: schema.objeto, dentro do database j\u00e1 conectado\r\nSELECT * FROM public.clientes;\r\n\r\n-- Tamb\u00e9m funciona, dois schemas do MESMO database\r\nSELECT c.nome, v.total\r\nFROM vendas.clientes c\r\nJOIN financeiro.vendas v ON v.cliente_id = c.id;\r\n\r\n-- N\u00c3O funciona: bancoa e bancob s\u00e3o databases diferentes\r\nSELECT * FROM bancoa.public.clientes c\r\nJOIN bancob.public.pedidos p ON p.cliente_id = c.id;\r\n-- ERROR: cross-database references are not implemented<\/code><\/span><\/pre>\n
Repare que cruzar schemas diferentes do mesmo database<\/strong> funciona sem nenhuma restri\u00e7\u00e3o especial \u2014 o limite \u00e9 sempre o database, nunca o schema.<\/p>\n
Passo a passo: criando database e schema no Postgres<\/h2>\n
# Cria um database novo (equivalente a CREATE DATABASE no SSMS)\r\nsudo -u postgres createdb bancoa\r\n\r\n# Conecta nele\r\nsudo -u postgres psql -d bancoa<\/code><\/span><\/pre>\n
-- Dentro do psql, j\u00e1 conectado em \"bancoa\"\r\n\r\n-- Cria um schema adicional (equivalente a CREATE SCHEMA no SQL Server)\r\nCREATE SCHEMA vendas;\r\n\r\n-- Define em que ordem os schemas s\u00e3o pesquisados quando o nome vem sem prefixo\r\nSET search_path TO vendas, public;\r\n\r\n-- Comandos de explora\u00e7\u00e3o no psql\r\n\\l          -- lista os databases do cluster\r\n\\c bancoa   -- conecta em outro database (na pr\u00e1tica, reconecta)\r\n\\dn         -- lista os schemas do database atual\r\n\\dt vendas.* -- lista as tabelas de um schema espec\u00edfico<\/code><\/span><\/pre>\n
O search_path<\/code> \u00e9 o equivalente funcional do schema padr\u00e3o do usu\u00e1rio no SQL Server: define em qual schema o Postgres procura um objeto quando voc\u00ea n\u00e3o escreve o prefixo. Sem configurar nada, o padr\u00e3o de f\u00e1brica j\u00e1 inclui public<\/code>.<\/p>\n
\n
De onde vem um database novo?<\/strong> Assim como o SQL Server usa o database model<\/code> como molde para todo database criado, o Postgres clona o database template1<\/code> por padr\u00e3o em todo CREATE DATABASE<\/code>\/createdb<\/code>. Alterar algo em template1<\/code> (uma extens\u00e3o, uma fun\u00e7\u00e3o utilit\u00e1ria) propaga para todo database novo criado depois. J\u00e1 template0<\/code> \u00e9 um molde “de f\u00e1brica”, intocado, usado para restaurar dumps com encoding\/collation diferentes do padr\u00e3o do cluster.<\/p>\n<\/div>\n
Por que cross-database query segue caminhos diferentes em cada banco<\/h2>\n
\u00c9 uma decis\u00e3o de arquitetura presente desde as origens do Postgres: cada database \u00e9 uma unidade de isolamento completa, com cat\u00e1logo pr\u00f3prio, controle de acesso pr\u00f3prio e visibilidade de transa\u00e7\u00e3o pr\u00f3pria. N\u00e3o existe join de execu\u00e7\u00e3o \u00fanica entre databases dentro do motor \u2014 qualquer cruzamento passa por uma camada expl\u00edcita.<\/p>\n
Quando voc\u00ea realmente precisa cruzar dados entre databases no mesmo cluster (ou at\u00e9 em servidores diferentes), as sa\u00eddas comuns s\u00e3o:<\/p>\n